1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-21 11:13:30 +00:00
freebsd/sys/ufs/lfs
David Greenman 0d94caffca These changes embody the support of the fully coherent merged VM buffer cache,
much higher filesystem I/O performance, and much better paging performance. It
represents the culmination of over 6 months of R&D.

The majority of the merged VM/cache work is by John Dyson.

The following highlights the most significant changes. Additionally, there are
(mostly minor) changes to the various filesystem modules (nfs, msdosfs, etc) to
support the new VM/buffer scheme.

vfs_bio.c:
Significant rewrite of most of vfs_bio to support the merged VM buffer cache
scheme.  The scheme is almost fully compatible with the old filesystem
interface.  Significant improvement in the number of opportunities for write
clustering.

vfs_cluster.c, vfs_subr.c
Upgrade and performance enhancements in vfs layer code to support merged
VM/buffer cache.  Fixup of vfs_cluster to eliminate the bogus pagemove stuff.

vm_object.c:
Yet more improvements in the collapse code.  Elimination of some windows that
can cause list corruption.

vm_pageout.c:
Fixed it, it really works better now.  Somehow in 2.0, some "enhancements"
broke the code.  This code has been reworked from the ground-up.

vm_fault.c, vm_page.c, pmap.c, vm_object.c
Support for small-block filesystems with merged VM/buffer cache scheme.

pmap.c vm_map.c
Dynamic kernel VM size, now we dont have to pre-allocate excessive numbers of
kernel PTs.

vm_glue.c
Much simpler and more effective swapping code.  No more gratuitous swapping.

proc.h
Fixed the problem that the p_lock flag was not being cleared on a fork.

swap_pager.c, vnode_pager.c
Removal of old vfs_bio cruft to support the past pseudo-coherency.  Now the
code doesn't need it anymore.

machdep.c
Changes to better support the parameter values for the merged VM/buffer cache
scheme.

machdep.c, kern_exec.c, vm_glue.c
Implemented a seperate submap for temporary exec string space and another one
to contain process upages. This eliminates all map fragmentation problems
that previously existed.

ffs_inode.c, ufs_inode.c, ufs_readwrite.c
Changes for merged VM/buffer cache.  Add "bypass" support for sneaking in on
busy buffers.

Submitted by:	John Dyson and David Greenman
1995-01-09 16:06:02 +00:00
..
lfs_alloc.c Cosmetics. make gcc less noisy. Still some way to go here. 1994-10-10 01:04:55 +00:00
lfs_balloc.c These changes embody the support of the fully coherent merged VM buffer cache, 1995-01-09 16:06:02 +00:00
lfs_bio.c Cosmetics. make gcc less noisy. Still some way to go here. 1994-10-10 01:04:55 +00:00
lfs_cksum.c
lfs_debug.c
lfs_extern.h
lfs_inode.c These changes embody the support of the fully coherent merged VM buffer cache, 1995-01-09 16:06:02 +00:00
lfs_segment.c These changes embody the support of the fully coherent merged VM buffer cache, 1995-01-09 16:06:02 +00:00
lfs_subr.c These changes embody the support of the fully coherent merged VM buffer cache, 1995-01-09 16:06:02 +00:00
lfs_syscalls.c These changes embody the support of the fully coherent merged VM buffer cache, 1995-01-09 16:06:02 +00:00
lfs_vfsops.c John Dyson's patches (and a few from me too) to LFS to use a different 1994-11-17 01:30:53 +00:00
lfs_vnops.c LFS stability patches. There is still a problem with directory update 1995-01-04 23:46:34 +00:00
lfs.h John Dyson's patches (and a few from me too) to LFS to use a different 1994-11-17 01:30:53 +00:00
README
TODO

#	@(#)README	8.1 (Berkeley) 6/11/93

The file system is reasonably stable, but incomplete.  There are
places where cleaning performance can be improved dramatically (see
comments in lfs_syscalls.c).  For details on the implementation,
performance and why garbage collection always wins, see Dr. Margo
Seltzer's thesis available for anonymous ftp from toe.cs.berkeley.edu,
in the directory pub/personal/margo/thesis.ps.Z, or the January 1993
USENIX paper.

Missing Functionality:
	Multiple block sizes and/or fragments are not yet implemented.

----------
The disk is laid out in segments.  The first segment starts 8K into the
disk (the first 8K is used for boot information).  Each segment is composed
of the following:

	An optional super block
	One or more groups of:
		segment summary
		0 or more data blocks
		0 or more inode blocks

The segment summary and inode/data blocks start after the super block (if
present), and grow toward the end of the segment.

	_______________________________________________
	|         |            |         |            |
	| summary | data/inode | summary | data/inode |
	|  block  |   blocks   |  block  |   blocks   | ...
	|_________|____________|_________|____________|

The data/inode blocks following a summary block are described by the
summary block.  In order to permit the segment to be written in any order
and in a forward direction only, a checksum is calculated across the
blocks described by the summary.  Additionally, the summary is checksummed
and timestamped.  Both of these are intended for recovery; the former is
to make it easy to determine that it *is* a summary block and the latter
is to make it easy to determine when recovery is finished for partially
written segments.  These checksums are also used by the cleaner.

	Summary block (detail)
	________________
	| sum cksum    |
	| data cksum   |
	| next segment |
	| timestamp    |
	| FINFO count  |
	| inode count  |
	| flags        |
	|______________|
	|   FINFO-1    | 0 or more file info structures, identifying the
	|     .        | blocks in the segment.
	|     .        |
	|     .        |
	|   FINFO-N    |
	|   inode-N    |
	|     .        |
	|     .        |
	|     .        | 0 or more inode daddr_t's, identifying the inode
	|   inode-1    | blocks in the segment.
	|______________|

Inode blocks are blocks of on-disk inodes in the same format as those in
the FFS.  However, spare[0] contains the inode number of the inode so we
can find a particular inode on a page.  They are packed page_size /
sizeof(inode) to a block.  Data blocks are exactly as in the FFS.  Both
inodes and data blocks move around the file system at will.

The file system is described by a super-block which is replicated and
occurs as the first block of the first and other segments.  (The maximum
number of super-blocks is MAXNUMSB).  Each super-block maintains a list
of the disk addresses of all the super-blocks.  The super-block maintains
a small amount of checkpoint information, essentially just enough to find
the inode for the IFILE (fs->lfs_idaddr).

The IFILE is visible in the file system, as inode number IFILE_INUM.  It
contains information shared between the kernel and various user processes.

	Ifile (detail)
	________________
	| cleaner info | Cleaner information per file system.  (Page
	|              | granularity.)
	|______________|
	| segment      | Space available and last modified times per
	| usage table  | segment.  (Page granularity.)
	|______________|
	|   IFILE-1    | Per inode status information: current version #,
	|     .        | if currently allocated, last access time and
	|     .        | current disk address of containing inode block.
	|     .        | If current disk address is LFS_UNUSED_DADDR, the
	|   IFILE-N    | inode is not in use, and it's on the free list.
	|______________|


First Segment at Creation Time:
_____________________________________________________________
|        |       |         |       |       |       |       |
| 8K pad | Super | summary | inode | ifile | root  | l + f |
|        | block |         | block |       | dir   | dir   |
|________|_______|_________|_______|_______|_______|_______|
	  ^
           Segment starts here.

Some differences from the Sprite LFS implementation.

1. The LFS implementation placed the ifile metadata and the super block
   at fixed locations.  This implementation replicates the super block
   and puts each at a fixed location.  The checkpoint data is divided into
   two parts -- just enough information to find the IFILE is stored in
   two of the super blocks, although it is not toggled between them as in
   the Sprite implementation.  (This was deliberate, to avoid a single
   point of failure.)  The remaining checkpoint information is treated as
   a regular file, which means that the cleaner info, the segment usage
   table and the ifile meta-data are stored in normal log segments.
   (Tastes great, less filling...)

2. The segment layout is radically different in Sprite; this implementation
   uses something a lot like network framing, where data/inode blocks are
   written asynchronously, and a checksum is used to validate any set of
   summary and data/inode blocks.  Sprite writes summary blocks synchronously
   after the data/inode blocks have been written and the existence of the
   summary block validates the data/inode blocks.  This permits us to write
   everything contiguously, even partial segments and their summaries, whereas
   Sprite is forced to seek (from the end of the data inode to the summary
   which lives at the end of the segment).  Additionally, writing the summary
   synchronously should cost about 1/2 a rotation per summary.

3. Sprite LFS distinguishes between different types of blocks in the segment.
   Other than inode blocks and data blocks, we don't.

4. Sprite LFS traverses the IFILE looking for free blocks.  We maintain a
   free list threaded through the IFILE entries.

5. The cleaner runs in user space, as opposed to kernel space.  It shares
   information with the kernel by reading/writing the IFILE and through
   cleaner specific system calls.