freebsd-dev/sys/ufs/ffs
Kirk McKusick 1c85e6a35d This commit adds basic support for the UFS2 filesystem. The UFS2
filesystem expands the inode to 256 bytes to make space for 64-bit
block pointers. It also adds a file-creation time field, an ability
to use jumbo blocks per inode to allow extent like pointer density,
and space for extended attributes (up to twice the filesystem block
size worth of attributes, e.g., on a 16K filesystem, there is space
for 32K of attributes). UFS2 fully supports and runs existing UFS1
filesystems. New filesystems built using newfs can be built in either
UFS1 or UFS2 format using the -O option. In this commit UFS1 is
the default format, so if you want to build UFS2 format filesystems,
you must specify -O 2. This default will be changed to UFS2 when
UFS2 proves itself to be stable. In this commit the boot code for
reading UFS2 filesystems is not compiled (see /sys/boot/common/ufsread.c)
as there is insufficient space in the boot block. Once the size of the
boot block is increased, this code can be defined.

Things to note: the definition of SBSIZE has changed to SBLOCKSIZE.
The header file <ufs/ufs/dinode.h> must be included before
<ufs/ffs/fs.h> so as to get the definitions of ufs2_daddr_t and
ufs_lbn_t.

Still TODO:
Verify that the first level bootstraps work for all the architectures.
Convert the utility ffsinfo to understand UFS2 and test growfs.
Add support for the extended attribute storage. Update soft updates
to ensure integrity of extended attribute storage. Switch the
current extended attribute interfaces to use the extended attribute
storage. Add the extent like functionality (framework is there,
but is currently never used).

Sponsored by: DARPA & NAI Labs.
Reviewed by:	Poul-Henning Kamp <phk@freebsd.org>
2002-06-21 06:18:05 +00:00
..
ffs_alloc.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_balloc.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_extern.h This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_inode.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_snapshot.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_softdep_stub.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_softdep.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_subr.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_tables.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_vfsops.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
ffs_vnops.c This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
fs.h This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +00:00
README.snapshot
README.softupdates
softdep.h This commit adds basic support for the UFS2 filesystem. The UFS2 2002-06-21 06:18:05 +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