Change default maximum ARC size to 1/4 of virtual memory on 32-bit systems

dmesg will print messages about virtual memory allocations failing
without this:

vmap allocation for size 528384 failed: use vmalloc=<size> to increase
size.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Linux 3.7 compat, schedule_delayed_work()

Linux kernel commit d8e794d accidentally broke the delayed work
APIs for non-GPL callers.   While the APIs to schedule a delayed
work item are still available to all callers, it is no longer
possible to initialize the work item.

I'm cautiously optimistic we can get the delayed_work_timer_fn
exported for all callers in the upstream kernel.  But until
that happens we can work around the issue by scheduling our
own timer and using it to dismatch the unmount to the system
taskq.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1053
Make upgrades to unsupported pre-feature flag pools trigger assertion

An assertion in spa.c is designed to prevent attempts to upgrade to
invalid pool versions.  It was written under the assumption that all
valid pools are less than SPA_VERSION. Since feature flags jumped from
28 to 5000, there any numbers in (28,5000) will fail to trigger the
assertion. We switch to the new SPA_VERSION_IS_SUPPORTED macro to
correct this.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
ZFS pool v29 support

This provides read support for pool version 29. Write support will
follow later.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Fix PaX/GrSecurity runtime error regression

Commit 8780c53961e668211682d40ad36946294c3145d8 reintroduced an
autotools check that is incompatible with the PaX/GrSecurity dialect of
C. This caused autotools checks to exhibit silent failures that
manifested as NULL pointer exceptions during runtime. A bug report
involving this was submitted to the gentoo bug tracker:

https://bugs.gentoo.org/show_bug.cgi?id=457176

This patch adapts the dirty inode check reintroduced by commit
8780c53961e668211682d40ad36946294c3145d8 to be semantically valid in the
PaX/GrSecurity dialect of C.

Reported-by: Marcin Mirosław <bug@mejor.pl>
Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Do not take zp->z_lock when updating zp->z_is_mapped

zp->z_is_mapped starts out life as B_FALSE, which is 0. When mmap() is
invoked, the znode lock is taken before an update to zp->z_is_mapped to
make it B_TRUE, which is 1. It never changes afterward and not a single
read of zp->z_is_mapped locks the znode. The consequence is that this
lock is unnecessary, so remove it.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Merge zvol.c changes from PSARC 2010/306 Read-only ZFS pools

The changes to zvol.c were never merged. This appears to have caused
regressions when importing pools read-only.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Align lz4_cache allocations

The original LZ4 source code suggests that that the hash table is
intended to fit entirely into the L1 data cache on Intel processors, but
the code makes no attempt to align its allocations to cache lines. This
is a bug in the original LZ4 code that should be corrected. However, it
does not affect Illumos' implementation.

These allocations are always aligned to a cacheline on Illumos because
the objects are powers of two and the objects are packed consecutively
in page aligned virtual allocations. Unfortunately, the SPL SLAB
allocator does not do this, which causes these allocations to often be
unaligned. We correct this by explicitly forcing 64-byte alignment,
which will guarentee proper alignment on Intel processors, as well as
many others.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>