mpp 0f6ed07b89 Quota system cleanup.
1) Do not do quota accounting for the actual quota data files
   or for file system snapshot files ("system" files).  This
   prevents a deadlock descibed in PR kern/30958 if the kernel
   ever has to grow the quota file.  Snapshot files were already
   exempt from the quota checks, but this change generalized the check.
2) Fix a cast that caused extremely large uids/gids to incorrectly
   write the quota information to the data file at a truncated
   value for a uint_t32 id value.  The incorrect cast caused quota
   files in this case to be around 4GB in size, with the correct cast
   they can now be 131GB in size.  Also related to PR kern/30958.
3) Check for what appear to be negative UIDs/GIDs and not account
   for them.  This prevents the quota files from becoming 131GB in
   size and causing quotacheck to run forever at bootup.  This could
   also cause the kernel to try and expand the quota file, which might
   deadlock due to the issue in #1.  kern/30958 and kern/38156
   (and some much older closed PR's).
4) With the deadlock problems gone, the kernel can now expand the
   size of the quota database files if it needs to.
5) Pass in the i-node count change value to chkiq and chkiqchg as an
   int, like it used to be before the common routine was split up
   into 2 different routines to increase / decrease the i-node in-use
   count.  Prevents an underflow on the i-node count.  Related
   to PR kern/89247.
6) Prevent the block usage from growing slowly if a file system is
   full and the write was denied due to that fact.  PR kern/89247.

Some of these changes require an updated quotacheck to prevent
the creation of huge (131GB) quota data files (item #3).

#1/#4 probably fixes a lot of the random hangs when quotas are enabled,
possibly some of the jail hangs.
2007-01-20 11:58:32 +00:00
..
2007-01-20 11:58:32 +00:00
2007-01-20 11:58:32 +00:00

$FreeBSD$

Using Soft Updates

To enable the soft updates feature in your kernel, add option
SOFTUPDATES to your kernel configuration.

Once you are running a kernel with soft update support, you need to enable
it for whichever filesystems you wish to run with the soft update policy.
This is done with the -n option to tunefs(8) on the UNMOUNTED filesystems,
e.g. from single-user mode you'd do something like:

	tunefs -n enable /usr

To permanently enable soft updates on the /usr filesystem (or at least
until a corresponding ``tunefs -n disable'' is done).


Soft Updates Copyright Restrictions

As of June 2000 the restrictive copyright has been removed and 
replaced with a `Berkeley-style' copyright. The files implementing
soft updates now reside in the sys/ufs/ffs directory and are
compiled into the generic kernel by default.


Soft Updates Status

The soft updates code has been running in production on many
systems for the past two years generally quite successfully.
The two current sets of shortcomings are:

1) On filesystems that are chronically full, the two minute lag
   from the time a file is deleted until its free space shows up
   will result in premature filesystem full failures. This
   failure mode is most evident in small filesystems such as
   the root. For this reason, use of soft updates is not
   recommended on the root filesystem.

2) If your system routines runs parallel processes each of which
   remove many files, the kernel memory rate limiting code may
   not be able to slow removal operations to a level sustainable
   by the disk subsystem. The result is that the kernel runs out
   of memory and hangs.

Both of these problems are being addressed, but have not yet
been resolved. There are no other known problems at this time.


How Soft Updates Work

For more general information on soft updates, please see:
	http://www.mckusick.com/softdep/
	http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/

--
Marshall Kirk McKusick <mckusick@mckusick.com>
July 2000