BSD Fast File System - Revision history

Jnc: /* Robustness */ typo

2025-05-22T10:49:05Z

‎Robustness: typo

Jnc: +Category

2025-05-22T10:43:41Z

+Category

Jnc: Link to online copy of 'Fast File System for UNIX'

2024-11-05T17:35:44Z

Link to online copy of 'Fast File System for UNIX'

Jnc: /* External links */ Link to archived version; main version is now offline

2024-11-05T17:28:36Z

‎External links: Link to archived version; main version is now offline

Jnc: +New cat

2023-06-12T17:20:34Z

+New cat

Jnc: typo

2022-10-28T14:12:44Z

typo

Jnc: add to new cat

2022-10-28T14:12:03Z

add to new cat

Jnc: +link to UFS; typos + tweaks

2022-09-07T12:12:51Z

+link to UFS; typos + tweaks

Jnc: /* Implementation details */ Minor clarifications, consisten terms

2019-04-07T10:59:18Z

‎Implementation details: Minor clarifications, consisten terms

Jnc: better cat

2018-12-31T18:45:46Z

better cat

@@ Line 51: / Line 51: @@
 Since the file system would be incomprehensible if the configuration values stored in the super-block were lost, a copy of the super-block was stored at the start of each cylinder group. (In the FFS, little to none of the data in the super-block changed while the system was operating, so it was not necessary to update all the copies whenever things changed on the disk.)
-Furthermore, the location of the copy is staggered in each cylinder group, so that there were on different platters (of a multi-platter [[disk pack]]), so that a single head crash could not take out all the copies.
+Furthermore, the location of the copy is staggered in each cylinder group, so that they were on different platters (of a multi-platter [[disk pack]]), so that a single head crash could not take out all the copies.
 Since the cylinder-group meta-data was stored immediately following the super-block copy, and the inodes following that, that information too was not all on a single platter, and vulnerable to a single hardware failure.

← Older revision		Revision as of 10:43, 22 May 2025
Line 100:		Line 100:

	[[Category: File Systems]]		[[Category: File Systems]]
		+	[[Category: UNIX]]
		+	[[Category: CSRG BSD]]
	[[Category: VAX Disk Formats]]		[[Category: VAX Disk Formats]]
−	~~[[Category: CSRG BSD]]~~

@@ Line 93: / Line 93: @@
 Similarly to the old file system, for large files, an inode also held the block numbers of a single indirect block (i.e. a block containing an array of block numbers), a double-indirect block (i.e. that block contained the block numbers of a set of indirect blocks), and a triple-indirect block.
+<!-- ==Further reading== -->
 ==External links==
-* [https://web.archive.org/web/20160811064613/http://www.cs.pomona.edu/~markk/filesystems/bsd.html Introduction to BSD UNIX Volume and File Structure]
+* [https://web.archive.org/web/20160811064613/http://www.cs.pomona.edu/~markk/filesystems/bsd.html Introduction to BSD UNIX Volume and File Structure] - very brief overview
+* Marshall K. McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry, [https://dsf.berkeley.edu/cs262/FFS-annotated.pdf ''A Fast File System for UNIX''] - detailed description
 [[Category: File Systems]]
 [[Category: VAX Disk Formats]]
 [[Category: CSRG BSD]]

@@ Line 96: / Line 96: @@
 ==External links==
-* [http://www.cs.pomona.edu/~markk/filesystems/bsd.html Introduction to BSD UNIX Volume and File Structure]
+* [https://web.archive.org/web/20160811064613/http://www.cs.pomona.edu/~markk/filesystems/bsd.html Introduction to BSD UNIX Volume and File Structure]
 ==Further reading==

← Older revision		Revision as of 17:20, 12 June 2023
Line 103:		Line 103:

	[[Category: File Systems]]		[[Category: File Systems]]
		+	[[Category: VAX Disk Formats]]
	[[Category: CSRG BSD]]		[[Category: CSRG BSD]]

← Older revision		Revision as of 14:12, 28 October 2022
Line 103:		Line 103:

	[[Category: File Systems]]		[[Category: File Systems]]
−	[[Category: CSRG ~~UNIX~~]]	+	[[Category: CSRG BSD]]

← Older revision		Revision as of 14:12, 28 October 2022
Line 102:		Line 102:
	Marshall K. McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry, ''A Fast File System for UNIX''		Marshall K. McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry, ''A Fast File System for UNIX''

−	[[Category: UNIX]]	+	[[Category: File Systems]]
		+	[[Category: CSRG UNIX]]

@@ Line 1: / Line 1: @@
-Until the creation of the '''Berkeley BSD Fast File System''' for [[BSD 4.1]], all prior [[UNIX]]es had used basically the [[file system]] designed for the early [[PDP-11]] versions of UNIX. While very simple (in on-[[disk]] structure, and thus implementation), it had some performance, functionality and robustness issues. The FFS fixed these, so successfully that the FFS and its descendants are still the file system of most Unix descendants today.
+Until the creation of the '''Berkeley BSD Fast File System''' for [[BSD 4.1]], all prior [[UNIX]]es had used basically the [[file system]] designed for the early [[PDP-11]] versions of UNIX, the [[UNIX file system]]. While very simple (in on-[[disk]] structure, and thus implementation), it had some performance, functionality and robustness issues. The FFS fixed these, so successfully that the FFS and its descendants are still the file system of most Unix descendants today.
 ==Issues==
-The performance issue were the most critical, but there were lesser functionality and robustness issue as well. The FFS fixed most of these issues (although without duplication of most meta-data, and all data, it was still somewhat susceptible to hardware failures such as [[head crash]]es).
+The performance issues were the most critical, but there were lesser functionality and robustness issues as well. The FFS fixed most of these issues (although without duplication of most meta-data, and all data, it was still somewhat susceptible to hardware failures such as [[head crash]]es).
 ===Performance===
@@ Line 9: / Line 9: @@
 The original Unix file system was too simple to be able to get good performance out of the disks of the BSD era.
-One factor was the small block size (which was to some extent ameliorated in systems prior to the FFS by using larger block sizes). Another was the fact that all the [[inode]]s were at the start of the disk, necessitating seeks (of average length of half the disk size) to get to the data. The last was the extreme non-locality of data placement, which was an endemic (albeit un-intended) feature of the earlier system.
+One factor was the small block size (which was to some extent ameliorated in systems prior to the FFS by using larger block sizes). Another was the fact that all the [[UNIX file system|inode]]s were at the start of the disk, necessitating seeks (of average length of half the disk size) to get to the data. The last was the extreme non-locality of data placement, which was an endemic (albeit un-intended) feature of the earlier system.
 Once the system had been running for a while, free blocks were scattered fairly randomly across the disk, and the blocks comprising a new file were thus widely scattered; reading the file resulted in a great deal of head motion (seeks). There was no cure for this state of affairs, other than dumping and re-building the disk - which would only solve the problem temporarily.
@@ Line 17: / Line 17: @@
 Although the original file system did include so-called [[hard link]]s, those were non-optimal in a lot of ways; among other issue, they were restricted to a single logical [[volume]].
-Another problematic limitation was the length of file names; although all [[ASCII]] characters could be used, the maximum length of any element (level) of a file name was only 14 characters.
+Another problematic limitation was the length of file names; although almost all [[ASCII]] characters could be used, the maximum length of any element (level) of a file name was only 14 characters.
 ===Robustness===
@@ Line 33: / Line 33: @@
 The 'block size' was increased substantially, although to prevent excessive wastage of space when storing small files, all blocks were divisible into ''fragments'' - which are actually the true 'block size' of the new file system; FFS 'blocks' are better thought of as a method to aggregate contiguous groups of fragments into a unit. When possible, fragments were coalesced back into a block.
-Instead of the old layout, with all the inodes at the start of the disk, the disk was divided into ''cylinder groups'', each of which contains a header containing information specific to that particular cyclinder group, a tranche of inodes (along with associated meta-data, such as free inode and fragment bit maps), and a number of data blocks. The cylinder-group header records (among other data) the numbers of free inodes, data blocks, and fragments in that cylinder group, to help the system select a cylinder group, when allocating new files.
+Instead of the old layout, with all the inodes at the start of the disk, the disk was divided into ''cylinder groups'', each of which contains a header containing information specific to that particular cylinder group, a tranche of inodes (along with associated meta-data, such as free inode and fragment bit maps), and a number of data blocks. The cylinder-group header records (among other data) the numbers of free inodes, data blocks, and fragments in that cylinder group, to help the system select a cylinder group, when allocating new files.
 Generally, an attempt is made to allocate all the storage for a file in the same cylinder group as its inode, so that seeks to retrieve the data are minimized. The blocks of a file are also placed on the disk in rotationally-optimized locations.
@@ Line 77: / Line 77: @@
 ==Implementation details==
-To start with, it is necessary to understand that the  FFS has no less than ''four'' different 'block' sizes:
+To start with, it is necessary to understand that the FFS has no less than ''four'' different 'block' sizes:
 * the hardware block size (512 bytes on DEC hardware), hereinafter 'sector' size;
 * the 'block device I/O block' size (normally statically defined as 2048 bytes - i.e. 4 sectors), which apparently was used for disk buffer allocation (hence the existence of the bdbtofsb() macro), but is not used in the file system anywhere;

@@ Line 84: / Line 84: @@
 Alas, the code is not always as clear as it could/should be as to which of these senses is in use in a particular structure element, etc. Note ''especially'' that disk addresses (e.g. 'block' numbers in inodes) are usually given in terms of fragment numbers.
-The disk starts with a hardware primary (1 sector) and secondary (15 sectors) bootstrap. The first copy of the super-block is immediately after that, at block 16.
+The disk starts with a hardware primary (1 sector) and secondary (15 sectors) bootstrap. The first copy of the super-block is immediately after that, at sector 16.
-From there on out, addresses may vary, depending on things such as the block-size parameter. A set of macros (cgbase(), cgstart(), etc) are provided to give the disk address (in units of fragments) of each part of a cylinder group; cgbase() indicates where the cylinder group starts, and cgstart() indicates where, within the cylinder group, the meta-data of that cylinder group resides.
+From there on out, physical disk addresses may vary, depending on things such as the block-size parameter. A set of macros (cgbase(), cgstart(), etc) are provided to give the disk address (in units of fragments) of each part of a cylinder group; cgbase() indicates where the cylinder group starts, and cgstart() indicates where, within the cylinder group, the meta-data of that cylinder group resides.
 For a file system with a fragment size of 2 sectors, and a block size of 8 sectors, the copy of the super-block for the first cylinder group is at sector 32, the cylinder group header for that cylinder-group is at sector 48, and the inodes start at sector 56.
-Inodes contained the block numbers of the first 12 blocks, so that all the data of files up to a fairly good size could be reached directly; all except the last one were necessarily full blocks, but the last one might contain only one or more fragments. The number of blocks, and the number of tailing fragments, could easily be determined from the file's size.
+Inodes contained the block numbers of the first 12 blocks of the file, so that all the data of files up to a fairly good size could be reached directly. All except the last one were necessarily full blocks, but the last one might contain only one or more fragments. The number of blocks, and the number of tailing fragments, could easily be determined from the file's size.
 Similarly to the old file system, for large files, an inode also held the block numbers of a single indirect block (i.e. a block containing an array of block numbers), a double-indirect block (i.e. that block contained the block numbers of a set of indirect blocks), and a triple-indirect block.

← Older revision		Revision as of 18:45, 31 December 2018
Line 102:		Line 102:
	Marshall K. McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry, ''A Fast File System for UNIX''		Marshall K. McKusick, William N. Joy, Samuel J. Leffler, Robert S. Fabry, ''A Fast File System for UNIX''

−	[[Category: ~~CSRG BSD~~]]	+	[[Category: UNIX]]