![]() |
Welcome to ftp.vim.org,
Hosted by ftp.nluug.nl Current directory: /pub/ftp/NetBSD/NetBSD-release-10/src/sys/ufs/lfs/ |
Contents of README:# $NetBSD: README,v 1.3 1999/03/15 00:46:47 perseant Exp $ # @(#)README 8.1 (Berkeley) 6/11/93 The file system is reasonably stable...I think. 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. ---------- 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. |
Name Last modified Size
Parent Directory -
CVS/ 17-Dec-2022 21:36 -
CHANGES 11-Dec-2005 13:25 8.0K
Makefile 28-Jul-2015 07:09 170
README 15-Mar-1999 01:46 5.9K
README.wc 06-Jun-2013 03:01 706
TODO 11-Dec-2005 13:25 5.3K
lfs.h 28-Mar-2020 02:08 50K
lfs_accessors.h 24-Apr-2022 22:32 47K
lfs_alloc.c 23-Feb-2020 09:49 25K
lfs_balloc.c 05-Sep-2020 18:30 20K
lfs_bio.c 05-Sep-2020 18:30 21K
lfs_cksum.c 02-Aug-2015 20:18 4.3K
lfs_debug.c 23-Feb-2020 09:39 11K
lfs_extern.h 23-Feb-2020 09:49 10K
lfs_inode.c 23-Apr-2020 23:47 28K
lfs_inode.h 23-Mar-2022 14:06 10K
lfs_itimes.c 10-Jun-2017 07:29 3.7K
lfs_kernel.h 20-Jun-2016 05:29 5.0K
lfs_pages.c 05-Sep-2020 18:30 26K
lfs_rename.c 20-Oct-2021 05:08 32K
lfs_rfw.c 05-Sep-2020 18:30 20K
lfs_segment.c 05-Sep-2020 18:30 77K
lfs_subr.c 05-Sep-2020 18:30 18K
lfs_syscalls.c 18-Feb-2020 21:23 27K
lfs_vfsops.c 19-Mar-2022 14:53 71K
lfs_vnops.c 20-Oct-2021 05:08 61K
ulfs_bmap.c 30-Mar-2017 11:10 13K
ulfs_bswap.h 19-Apr-2018 23:50 2.7K
ulfs_dinode.h 20-Jun-2016 05:25 2.8K
ulfs_dirhash.c 07-Aug-2022 04:33 34K
ulfs_dirhash.h 19-Aug-2021 22:56 5.2K
ulfs_extattr.c 30-Jun-2021 00:40 41K
ulfs_extattr.h 20-Jun-2016 03:56 4.7K
ulfs_extern.h 19-Jul-2021 01:57 5.2K
ulfs_inode.c 05-Sep-2020 18:30 7.4K
ulfs_inode.h 10-Jun-2017 07:29 8.1K
ulfs_lookup.c 06-Aug-2022 20:26 37K
ulfs_quota.c 20-Jun-2016 01:06 24K
ulfs_quota.h 20-Jun-2016 05:29 6.1K
ulfs_quota1.c 30-Jun-2021 00:40 23K
ulfs_quota1.h 20-Jun-2016 05:29 4.4K
ulfs_quota1_subr.c 25-Jul-2021 08:10 3.1K
ulfs_quota2.c 29-May-2022 00:08 41K
ulfs_quota2.h 06-Jun-2013 02:49 4.7K
ulfs_quota2_subr.c 06-Jun-2013 02:51 4.3K
ulfs_quotacommon.h 08-Jun-2013 04:04 3.1K
ulfs_readwrite.c 20-Oct-2021 05:08 15K
ulfs_snapshot.c 05-Sep-2020 18:30 2.8K
ulfs_vfsops.c 17-Jan-2020 21:08 6.3K
ulfs_vnops.c 27-Mar-2022 18:24 31K
ulfsmount.h 20-Jun-2016 05:36 4.2K
NLUUG - Open Systems. Open Standards
Become a member
and get discounts on conferences and more, see the NLUUG website!