Always allow '-o remount,ro'

Allow the mount(8) utility to always operate on all datasets when
remounting them read-only.  This critical for rc.sysinit/umountroot
which remounts the root filesystem read-only during shutdown to
ensure everything is correctly flushed to disk.

Fix minor typo, the check to set zfsutil should use the bitwise
'&'.  I must have accidentally hit the adjacent '*' and obviously
neither the compiler or my code review caught this.  Fix it now.
Strip 'zfsutil,remount' from /etc/mtab

When updating /etc/mtab we should be careful and strip certain
options.  In particular, we need to strip 'zfsutil' because if
we don't the mount utility will helpfull provide it to the
mount helper when we issue mount(8) again.  This subverts the
check that the caller is zfs(8) and not mount(8).
Register .sync_fs handler

Register the missing .sync_fs handler.  This is a noop in most cases
because the usual requirement is that sync just be initiated.  As part
of the DMU's normal transaction processing txgs will be frequently
synced.  However, when the 'wait' flag is set the requirement is that
.sync_fs must not return until the data is safe on disk.  With the
addition of the .sync_fs handler this is now properly implemented.
Register .remount_fs handler

Register the missing .remount_fs handler.  This handler isn't strictly
required because the VFS does a pretty good job updating most of the
MS_* flags.  However, there's no harm in using the hook to call the
registered zpl callback for various MS_* flags.  Additionaly, this
allows us to lay the ground work for more complicated argument parsing
in the future.
Add init scripts

To support automatically mounting your zfs on filesystem on boot
a basic init script is needed.  Unfortunately, every distribution
has their own idea of the _right_ way to do things.  Rather than
write one very complicated portable init script, which would be
invariably replaced by the distributions own anyway.  I have
instead added support to provide multiple distribution specific
init scripts.

The correct init script for your distribution will be selected
by ZFS_AC_DEFAULT_PACKAGE which will set DEFAULT_INIT_SCRIPT.
During 'make install' the correct script for your system will
be installed from zfs/etc/init.d/zfs.DEFAULT_INIT_SCRIPT to the
usual /etc/init.d/zfs location.

Currently, there is zfs.fedora and a more generic zfs.lsb init
script.  Hopefully, the distribution maintainers who know best
how they want their init scripts to function will feedback their
approved versions to be included in the project.

This change does not consider upstart jobs but I'm not at all
opposed to add that sort of thing.
Add dracut support

To simplify the process of using zfs as your root filesystem a
zfs-drucat sub-package has been added.  This sub-package adds a zfs
dracut module which allows your initramfs to be rebuilt with zfs
support.  The process for doing this is still complicated but there
is clearly interest from the community about getting this working
well and documented.  This should help lay some of the groundwork.

Longer term these changes should be pushed in the upstream dracut
package.  Once that occurs this subpackage will no longer be
required for new systems, however we may want to conditionally
build this package in the future for systems running older
dracut versions.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Use KM_PUSHPAGE instead of KM_SLEEP

It used to be the case that all KM_SLEEP allocations were GFS_NOFS.
Unfortunately this often resulted in the kernel being unable to
reclaim the ARC, inode, and dentry caches in a timely manor.
The fix was to make KM_SLEEP a GFP_KERNEL allocation in the SPL.

However, this increases the posibility of deadlocking the system
on a zfs write thread.  If a zfs write thread attempts to perform
an allocation it may trigger synchronous reclaim.  This reclaim
may attempt to flush dirty data/inode to disk to free memory.
Unforunately, this write cannot finish because the write thread
which would handle it is holding the previous transaction open.
Deadlock.

To avoid this all allocations in the zfs write thread path must
use KM_PUSHPAGE which prohibits synchronous reclaim for that
thread.  In this way forward progress in ensured.  The risk
with this change is I missed updating an allocation for the
write threads leaving an increased posibility of deadlock.  If
any deadlocks remain they will be unlikely but we'll have to
make sure they all get fixed.
Fix evict() deadlock

Now that KM_SLEEP is not defined as GFP_NOFS there is the possibility
of synchronous reclaim deadlocks.  These deadlocks never existed in the
original OpenSolaris code because all memory reclaim on Solaris is done
asyncronously.  Linux does both synchronous (direct) and asynchronous
(indirect) reclaim.

This commit addresses a deadlock caused by inode eviction.  A KM_SLEEP
allocation may trigger direct memory reclaim and shrink the inode cache.
This can occur while a mutex in the array of ZFS_OBJ_HOLD mutexes is
held.  Through the ->shrink_icache_memory()->evict()->zfs_inactive()->
zfs_zinactive() call path the same mutex may be reacquired resulting
in a deadlock.  To avoid this deadlock the process must not reacquire
the mutex when it is already holding it.

This is a reasonable fix for now but longer term the ZFS_OBJ_HOLD
mutex locking should be reevaluated.  This infrastructure already
prevents us from ever using the Linux lock dependency analysis tools,
and it may limit scalability.
Linux compat, umount2(2) flags

Older glibc <sys/mount.h> headers did not define all the available
umount2(2) flags.  Both MNT_FORCE and MNT_DETACH are supported in the
kernel back to 2.4.11 so we define them correctly if they are missing.

Closes #95
Linux 2.6.27 compat, blk_queue_stackable()

The blk_queue_stackable() queue flag was added in 2.6.27 to handle dm
stacking drivers.  Prior to this request stacking drivers were detected
by checking (q->request_fn == NULL), for earlier kernels we revert to
this legacy behavior.
Linux 2.6.28 compat, insert_inode_locked()

Added insert_inode_locked() helper function, prior to this most callers
used insert_inode_hash().  The older method doesn't check for collisions
in the inode_hashtable but it still acceptible for use.  Fallback to
using insert_inode_hash() when insert_inode_locked() is unavailable.
Linux 2.6.29 compat, credentials

As of Linux 2.6.29 a clean credential API was added to the Linux kernel.
Previously the credential was embedded in the task_struct.  Because the
SPL already has considerable support for handling this API change the
ZPL code has been updated to use the Solaris credential API.
Linux 2.6.29 compat, .freeze_fs/.unfreeze_fs

The .freeze_fs/.unfreeze_fs hooks were not added until Linux 2.6.29
Since these hooks are currently unused they are being removed to
allow support of older kernels.
Fixes to enable zvol symlink creation

This commit fixes issue on
https://github.com/behlendorf/zfs/issues/#issue/172
Changes:
- update BLKZNAME to use _IOR instead of _IO.  Kernel 2.6.32 allows
read parameters (copy_to_user) with _IO, while newer kernels (tested
Archlinux's 2.6.37 kernel) enforces _IOR (which is correct)
- fix return code and message on error

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Set cmd paths in udev rules using --prefix

The udev/rules.d scripts must use absolute paths to their support
binaries.  However, where those binaries get installed depends
on what --prefix was set to when the package was configured.
This change makes the udev/rules.d helpers to *.in files which
are processed by configure.  This allows them to be dynamically
updated to include the specified --prefix.

Additionally, this change updates 60-zvol.rules to handle both
the 'add' and 'change' actions.  This ensures that that all
valid zvol devices are correctly linked.
Spec file compat, %{datadir}

The dracut change caused an error during "make rpm".  The cause
is simple, RHEL5 does not recognize the %{datarootdir} macro in
zfs.spec.  It was changed to %{datadir} which fixes the build.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fix inflated load average

Kernel threads which sleep uninterruptibly on Linux are marked in the (D)
state.  These threads are usually in the process of performing IO and are
thus counted against the load average.  The txg_quiesce and txg_sync threads
were always sleeping uninterruptibly and thus inflating the load average.

This change makes them sleep interruptibly.  Some care is required however
because these threads may now be woken early by signals.  In this case the
callers are all careful to check that the required conditions are met after
waking up.  If we're woken early due to a signal they will simply go back
to sleep.  In this case these changes are safe.

Closes #175
Fix libzpool cv_* build error

This build failure was accidentally introduced by previous commit
bfd214a which fixed the load average.  Unfortunately, the wrapper
for cv_wait_interruptible was not available in the zfs_context.h
user compatibility code.  I failed to notice this because I didn't
rebuild everything cleanly before committing.

  undefined reference to `cv_wait_interruptible'
  collect2: ld returned 1 exit status

Closes #181
Update CHAOS 5 Packaging

The CHAOS 5 kernels are now packaged identially to the RHEL6 kernels.
Therefore we can simply use the RHEL6 rules in the spec file when
building packages.
Call udevadm trigger more safely

Some udev hooks are not designed to be idempotent, so calling udevadm
trigger outside of the distribution's initialization scripts can have
unexpected (and potentially dangerous) side effects.  For example, the
system time may change or devices may appear multiple times.  See Ubuntu
launchpad bug 320200 and this mailing list post for more details:

https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html

To avoid these problems we call udevadm trigger with --action=change
--subsystem-match=block.  The first argument tells udev just to refresh
devices, and make sure everything's as it should be.  The second
argument limits the scope to block devices, so devices belonging to
other subsystems cannot be affected.

This doesn't fix the problem on older udev implementations that don't
provide udevadm but instead have udevtrigger as a standalone program.
In this case the above options aren't available so there's no way to
call call udevtrigger safely.  But we can live with that since this
issue only exists in optional test and helper scripts, and most
zfs-on-linux users are running newer systems anyways.