UNIX file system - Revision history

Jnc: /* See also */ +BSD Fast File System

2025-05-22T10:40:11Z

Jnc: /* External links */ +UNIX Implementation

2023-06-14T12:34:57Z

External links: +UNIX Implementation

← Older revision		Revision as of 12:34, 14 June 2023
Line 41:		Line 41:
	==External links==		==External links==

			* [https://cseweb.ucsd.edu//classes/wi19/cse221-a/papers/thompson78.pdf UNIX Implementation] - a Thompson paper which gives an overview of the implementation of the file system
	* [http://squoze.net/UNIX/v5man/man5/fs fs(V)] - short but clear detailed specification of the V5 file system		* [http://squoze.net/UNIX/v5man/man5/fs fs(V)] - short but clear detailed specification of the V5 file system
	* [http://squoze.net/UNIX/v5man/man5/directory directory(V)]		* [http://squoze.net/UNIX/v5man/man5/directory directory(V)]

Jnc: +New cats

2023-06-12T17:23:31Z

+New cats

← Older revision		Revision as of 17:23, 12 June 2023
Line 47:		Line 47:

	[[Category: File Systems]]		[[Category: File Systems]]
			[[Category: PDP-11 Disk Formats]]
			[[Category: VAX Disk Formats]]
	[[Category: UNIX]]		[[Category: UNIX]]

Jnc: Minor clarifications/improvements

2023-05-15T15:12:46Z

Minor clarifications/improvements

← Older revision		Revision as of 15:12, 15 May 2023
Line 1:		Line 1:
	The '''UNIX file system''' was one of the first [[file system]]s to internally separate [[directory\|directories]] (the catalogues of [[file]]s) from the meta-data about a file (such as the information about where the data of the file was stored).		The '''UNIX file system''' was one of the first [[file system]]s to internally completely separate [[directory\|directories]] (the catalogues of [[file]]s) from the meta-data about a file (such as the information about where the data of the file was stored).

	It did this through the mechanism of the '''inode''', a separate structure, in which most of the information about a file was kept. Directories were implemented as an abstraction on top of the previous layer), using 'file' objects provided by the inode layer; ~~they~~ only held mappings from file-names (visible to users) to inode numbers.		[[UNIX]] did this through the mechanism of the '''inode''', a separate structure, in which most of the information about a file was kept. Directories were implemented as an abstraction on top of the previous layer), using 'file' objects provided by the inode layer; directory files only held mappings from file-names (visible to users) to inode numbers (used internally by the [[operating system]], and generally not visible to users).

	The inodes themselves were held in a separate area of the disk, outside the area used to hold the blocks of the files themselves~~, the '''ilist'''~~. A special block, the '''root block''' (also called the '''super-block''') - initially held in block 0, later block 1, on the [[disk partition]] - held information about which blocks in the partition held the inodes, which blocks were available to hold data, and other general information about the file system on that partition.		The inodes themselves were held in an inode table, the '''ilist''', kept in a separate area of the disk, outside the area used to hold the blocks of the files themselves. A special block, the '''root block''' (also called the '''super-block''') - initially held in block 0, later block 1, on the [[disk partition]] - held information about which blocks in the partition held the inodes, which blocks were available to hold data, and other general information about the file system on that partition.

	==Details==		==Details==
Line 17:		Line 17:
	==Evolution==		==Evolution==

	Within the above general scheme, the UNIX file system evolved in minor ways over time. After [[UNIX Fourth Edition‎]], the inode indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files.		Within the above general scheme, the UNIX file system evolved in minor ways over time. After [[UNIX Fourth Edition‎]], the inode itself indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files.

	Also starting with V4, information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a separate bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the ~~inode table~~ on the disk refilled it. (Hopefully!)		Also starting with V4, information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a separate bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the ilist on the disk refilled it. (Hopefully!)

	V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of the latest); but V6 includes support for extra-large (huge) files. In these, the last indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.		V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of the latest); but V6 includes support for extra-large (huge) files. In these, the last indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.
Line 25:		Line 25:
	Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, in theory it could be somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If a V6 file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on it.		Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, in theory it could be somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If a V6 file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on it.

	By the time of [[Unix Seventh Edition]], disks had grown in size to the point that use of 16-bit block numbers were a serious handicap. Prior to V7, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.		By the time of [[Unix Seventh Edition]], disks had grown in size to the point that use of 16-bit block numbers were a serious handicap. Prior to V7, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and had a number of other minor changes.

	==Further evolution==		==Further evolution==

Jnc: /* Evolution */ Minor clarifications

2023-03-12T13:20:19Z

Evolution: Minor clarifications

← Older revision		Revision as of 13:20, 12 March 2023
Line 17:		Line 17:
	==Evolution==		==Evolution==

	After [[UNIX Fourth Edition‎]], the inode indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files.		Within the above general scheme, the UNIX file system evolved in minor ways over time. After [[UNIX Fourth Edition‎]], the inode indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files.

	Also starting with V4, information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a separate bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the inode table on the disk refilled it. (Hopefully!)		Also starting with V4, information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a separate bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the inode table on the disk refilled it. (Hopefully!)

	V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of ~~either~~); but V6 includes support for extra-large (huge) files. In these, the last ~~(8th)~~ indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.		V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of the latest); but V6 includes support for extra-large (huge) files. In these, the last indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.

	Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, in theory it could be somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If ~~the~~ file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on ~~either kind of early file system~~.		Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, in theory it could be somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If a V6 file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on it.

	By the time of [[Unix Seventh Edition]], disks had grown in size to the point that 16-bit block numbers were a serious handicap. Prior to ~~that~~, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.		By the time of [[Unix Seventh Edition]], disks had grown in size to the point that use of 16-bit block numbers were a serious handicap. Prior to V7, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.

	==Further evolution==		==Further evolution==

Jnc: /* Evolution */ More accurate about max size

2023-03-12T09:29:42Z

Evolution: More accurate about max size

← Older revision		Revision as of 09:29, 12 March 2023
Line 23:		Line 23:
	V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of either); but V6 includes support for extra-large (huge) files. In these, the last (8th) indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.		V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of either); but V6 includes support for extra-large (huge) files. In these, the last (8th) indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.

	Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, it is somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If the file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on either kind of early file system.		Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, in theory it could be somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If the file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on either kind of early file system.

	By the time of [[Unix Seventh Edition]], disks had grown in size to the point that 16-bit block numbers were a serious handicap. Prior to that, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.		By the time of [[Unix Seventh Edition]], disks had grown in size to the point that 16-bit block numbers were a serious handicap. Prior to that, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.

Jnc: Cover evolution through V6 and V7

2023-03-11T22:50:43Z

Cover evolution through V6 and V7

← Older revision		Revision as of 22:50, 11 March 2023
Line 7:		Line 7:
	==Details==		==Details==

	~~Starting with [[UNIX Fourth Edition‎]], information about which blocks were 'free', and available to be allocated to~~ files, ~~was kept in a 'free [[list]]'~~ of blocks~~, the head~~ of ~~which~~ was kept in the ~~root block~~. ~~(Prior~~ to V4, ~~this information was kept~~ in ~~a bit [[array]].) When a partition was initialized as a file system,~~ the ~~free list was constructed to hold all~~ the ~~blocks available~~ for ~~files. Similarly, starting in V4,~~ the ~~root~~ block ~~also held a [[cache]]~~ of ~~free inodes~~; ~~when this was exhausted, a sweep~~ of the inode ~~table on the disk refilled it~~. ~~(Hopefully!)~~		For the sake of efficiency (there are many more small files than large ones), the location of the first few blocks of a file was kept in the inode itself. If a file needed to grow past that, '''indirect blocks''' were used; these were blocks (stored in the area of the disk used for file data) which held an array of the block numbers of the actual blocks of the file; the block numbers of the indirect blocks were held in the inode.

	~~For the sake of efficiency (there are many more small files than large ones), the location of the first few blocks of a~~ file ~~was kept in the inode itself. If a file needed to grow past that,~~ ''~~'indirect blocks''' were used~~; ~~these were blocks (stored~~ in the ~~area of the disk used for file data) which held an array~~ of ~~the~~ block numbers ~~of the actual blocks of the file; the block numbers of the indirect blocks were held~~ in the inode~~. For even larger files~~, ~~the last~~ indirect ~~block listed in the inode did not contain the block numbers of data~~ blocks, ~~but rather the~~ block ~~numbers~~ of ~~'double-indirect blocks'~~, ~~which then held the block numbers of~~ '~~ordinary~~' ~~indirect~~ blocks.		The file system allowed 'holey' files; in the tables of block numbers (either in the inode, or in indirect blocks), a block number of 0 indicated that block had never been written to, and thus never allocated. The UNIX file I/O system allowed users to write data wherever they wanted within a file, leaving gaps if they so desired. Such 'missing' blocks contained all zeros when read.

	The file system allowed 'holey' files; in the tables of block numbers (either in the inode, or in both types of indirect blocks), a block number of 0 indicated that block had never been written to, and thus never allocated. The UNIX file I/O system allowed users to write data wherever they wanted within a file, leaving gaps if they so desired. Such 'missing' blocks contained all zeros when read.		Inodes also held information such as the length of the file, whether the file was actually a directory (treated specially by the system, in that only the system could write to it, to prevent users from damaging the file system), the owner of the file, the file's protection, and last modification and access times, etc.

	Inodes also held information such as the length of the file, whether the file was actually a directory (treated specially by the system, in that only the system could write to it, to prevent users from damaging the file system), the owner of the file, the file's protection, and last modification and access times, etc~~. After V4, the inode indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files~~.

	Finally, the inode held a count of the number of [[hard link]]s to the file; a given file could appear in more than one directory, and the count was needed to [[garbage collection\|garbage collect]] the file's blocks when the last directory entry for it was deleted. All directory entries for a file were equal; none had special status.		Finally, the inode held a count of the number of [[hard link]]s to the file; a given file could appear in more than one directory, and the count was needed to [[garbage collection\|garbage collect]] the file's blocks when the last directory entry for it was deleted. All directory entries for a file were equal; none had special status.
Line 19:		Line 17:
	==Evolution==		==Evolution==

	~~The~~ UNIX file system, ~~as described above~~, ~~lasted quite~~ a ~~long time~~; ~~minor detail changes were made over time~~ (e.g. in [[Unix Seventh Edition~~\|Unix V7~~]], block numbers were increased in size from 16 bits to 32~~), but in general the above description of~~ the ~~details applied~~ to ~~most versions~~ of ~~UNIX before [[BSD 4.1b]]~~.		After [[UNIX Fourth Edition‎]], the inode indicated whether it was a 'special file', for a [[peripheral\|device]], rather than an ordinary file; before V4, inodes 1-40. were reserved for special files.

			Also starting with V4, information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a separate bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the inode table on the disk refilled it. (Hopefully!)

			V4, V5 and V6 file systems are almost identical (to the point that most tools for the early versions of the file system will work on most instances of either); but V6 includes support for extra-large (huge) files. In these, the last (8th) indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks. PWB/UNIX, although mostly V6, does not support extra-large files.

			Without extra-large files, the largest file supported is 5122568=1,048,576 bytes; with extra-large files, it is somewhat larger than 256256512=33,554,432 bytes - but the length of a file is stored in a 24-bit field in the inode, so in practice a file in a V6 file system can be at most 16,777,216 bytes long. If the file system does not have any files longer than 5122567=917,504 bytes, this distinction can be ignored; all the early tools will work on either kind of early file system.

			By the time of [[Unix Seventh Edition]], disks had grown in size to the point that 16-bit block numbers were a serious handicap. Prior to that, larger disks had been handled by splitting them into partitions, with none being larger than 2^16=65,536 blocks. In V7, block numbers were increased in size from 16 bits to 32; the inode format was changed to accommodate this, and a number of other minor changes.

			==Further evolution==

	As UNIX became used for larger and larger machines, two aspects of the file system became problematic: performance, and robustness.		The UNIX file system, as described above, lasted quite a long time; minor detail changes were made over time, but in general the above description of the details applied to most versions of UNIX before [[BSD 4.1b]]. As UNIX became used for larger and larger machines, however, two aspects of the file system became problematic: performance, and robustness.

	The former was basically caused by the tendency of the UNIX file system to scatter the blocks of a file (especially large data files, where performance was more of an issue) across the entire disk, once the file system had been in use for a while. The latter was caused by the fact that there was only a single copy of much critical information, e.g. the root block.		The former was basically caused by the tendency of the UNIX file system to scatter the blocks of a file (especially large data files, where performance was more of an issue) across the entire disk, once the file system had been in use for a while. The latter was caused by the fact that there was only a single copy of much critical information, e.g. the root block.
Line 33:		Line 41:
	==External links==		==External links==

	* [http://squoze.net/UNIX/v5man/man5/fs fs(V)] - short but clear detailed specification		* [http://squoze.net/UNIX/v5man/man5/fs fs(V)] - short but clear detailed specification of the V5 file system
	* [http://squoze.net/UNIX/v5man/man5/directory directory(V)]		* [http://squoze.net/UNIX/v5man/man5/directory directory(V)]
			* [https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5 fs(V)] - the V6 file system description
			* [https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man5/filsys.5 filsys(V)] - the V7 file system description

	[[Category: File Systems]]		[[Category: File Systems]]
	[[Category: UNIX]]		[[Category: UNIX]]

Jnc: /* External links */ +relevant UPM sections

2023-03-03T11:41:01Z

External links: +relevant UPM sections

← Older revision		Revision as of 11:41, 3 March 2023
Line 26:		Line 26:

	A major modification to the UNIX file system was therefore done, the [[BSD Fast File System]]. It kept the basic concept of the two-level system, with inodes and directories, but made extensive detail changes (e.g. having multiple copies of the root block, scattered across the disk) to address the efficiency and robustness issues.		A major modification to the UNIX file system was therefore done, the [[BSD Fast File System]]. It kept the basic concept of the two-level system, with inodes and directories, but made extensive detail changes (e.g. having multiple copies of the root block, scattered across the disk) to address the efficiency and robustness issues.

			==See also==

			* [[Repairing early UNIX file systems]]

			==External links==

			* [http://squoze.net/UNIX/v5man/man5/fs fs(V)] - short but clear detailed specification
			* [http://squoze.net/UNIX/v5man/man5/directory directory(V)]

	[[Category: File Systems]]		[[Category: File Systems]]
	[[Category: UNIX]]		[[Category: UNIX]]

Jnc: add to new cat

2022-10-28T14:13:56Z

add to new cat

← Older revision		Revision as of 14:13, 28 October 2022
Line 27:		Line 27:
	A major modification to the UNIX file system was therefore done, the [[BSD Fast File System]]. It kept the basic concept of the two-level system, with inodes and directories, but made extensive detail changes (e.g. having multiple copies of the root block, scattered across the disk) to address the efficiency and robustness issues.		A major modification to the UNIX file system was therefore done, the [[BSD Fast File System]]. It kept the basic concept of the two-level system, with inodes and directories, but made extensive detail changes (e.g. having multiple copies of the root block, scattered across the disk) to address the efficiency and robustness issues.

			[[Category: File Systems]]
	[[Category: UNIX]]		[[Category: UNIX]]

Jnc: /* Details */ +link

2022-07-01T11:44:28Z

Details: +link

← Older revision		Revision as of 11:44, 1 July 2022
Line 7:		Line 7:
	==Details==		==Details==

	Starting with [[UNIX Fourth Edition‎]], information about which blocks were 'free', and available to be allocated to files, was kept in a 'free list', the head of which was kept in the root block. (Prior to V4, this information was kept in a bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the inode table on the disk refilled it. (Hopefully!)		Starting with [[UNIX Fourth Edition‎]], information about which blocks were 'free', and available to be allocated to files, was kept in a 'free [[list]]' of blocks, the head of which was kept in the root block. (Prior to V4, this information was kept in a bit [[array]].) When a partition was initialized as a file system, the free list was constructed to hold all the blocks available for files. Similarly, starting in V4, the root block also held a [[cache]] of free inodes; when this was exhausted, a sweep of the inode table on the disk refilled it. (Hopefully!)

	For the sake of efficiency (there are many more small files than large ones), the location of the first few blocks of a file was kept in the inode itself. If a file needed to grow past that, '''indirect blocks''' were used; these were blocks (stored in the area of the disk used for file data) which held an array of the block numbers of the actual blocks of the file; the block numbers of the indirect blocks were held in the inode. For even larger files, the last indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks.		For the sake of efficiency (there are many more small files than large ones), the location of the first few blocks of a file was kept in the inode itself. If a file needed to grow past that, '''indirect blocks''' were used; these were blocks (stored in the area of the disk used for file data) which held an array of the block numbers of the actual blocks of the file; the block numbers of the indirect blocks were held in the inode. For even larger files, the last indirect block listed in the inode did not contain the block numbers of data blocks, but rather the block numbers of 'double-indirect blocks', which then held the block numbers of 'ordinary' indirect blocks.

← Older revision		Revision as of 10:40, 22 May 2025
Line 38:		Line 38:

	* [[Repairing early UNIX file systems]]		* [[Repairing early UNIX file systems]]
			* [[BSD Fast File System]]

	==External links==		==External links==