Talk:Ext2
ctime
I changed the description of ctime to "change time of inode", and it was reverted on the basis of what ext2_fs.h says. I disagree with this, so I have put my change back again. — PhilHibbs | talk 12:16, 2 Mar 2005 (UTC)
Berkeley Fast File System background
The guys who wrote Unix System Administration Handbook page 151 mentions somewhere that Ext2 borrows its concepts from FFS. How true is this claim? After googling a bit, i came across a couple of links and it looks like they generalized it too far. See [1] specifically "ext2 file system is an intellectual descendant of the Berkeley Fast File System". I just mentioned it as it wouldn't hurt leveraging views from different sources.
(unsigned)
Ext2 is mostly a UFS filesystem with some VAX-era cruft stripped out.
UFS was designed for disks that actually used cylinder-head-sector addressing with a known interleave. You could set up UFS to be aware of this, avoiding some delays related to disk rotation. Such hacks are essentially impossible on modern hardware. When ext2 was being developed, UFS lost performance in a futile effort to optimize for something it could not know. Modern UFS doesn't try to play such games, but still retains the now-worthless on-disk data structures.
UFS traditionally used 8 K blocks with 1 K sub-blocks for file tails. More recently, the sizes are half of that. Ext2's normal block size range is 1 K, 2 K, or 4 K. Plans to implement fragments for Linux have been cancelled because the feature adds complexity and, unsurprisingly, fragmentation.
UFS has the 3 traditional UNIX file timestamps. Ext2 adds a fourth, the deletion time. This helps the filesystem checker to be more reliable. It costs an extra seek when a file is deleted.
Ext2 replicates the superblock in many places for extra reliability. During recovery from a disaster, the filesystem checker can locate a backup superblock if needed.
In the HURD variant, there is an author ID.
The file flags are a bit different.
Recent enhancements include ACLs, OS/2-style extended attributes (small named forks), security data tags, file type info in directory entries, growable filesystems, journalling (ext3), and hashed directories.
Non-standard enhancements include compression, extent-based block allocation, phase-tree commits, and tree-structured tail packing.
The ext2 driver never seriously attempted to support sync operation. Despite this, recovery from crashes was generally superior to that of UFS because the ext2.fsck program was a truly excellent piece of software.
GNU & Kernel
Instead "used on the Linux operating system", how about "used in the Linux kernel". This is probably more accurate than "Linux operating system" or "GNU/Linux operating system". Jebba 06:51, 25 July 2005 (UTC) Also, this article is probably no longer a stub.
Design
The incomplete "Design" section was a bit of an eyesore. I'm moving its contents in here until I can find time for a full write-up. —Ghakko 22:35, 27 July 2005 (UTC)
- Block group
- Every ext2 filesystem is divided up into block groups, each of which has its own:
- Superblock
- Group descriptors
- Block bitmap
- Inode bitmap
- Inode table
- Data blocks
- Block groups are similar to cylinder groups in Berkeley FFS, where they were introduced to retard file fragmentation.
- Superblock
- The superblock contains metadata describing the entire filesystem:
- Number of inodes
- Number of blocks
- Reserved block count
- First data block number
- Block size
- Fragment size
- Number of blocks per group
- Number of fragments per group
- Number of inodes per group
- Mount time
- Write time
- Mount count
- Maximal mount count
- Magic signature
- File system state: valid (unmounted cleanly) or error
- Error detection behavior
- Minor revision level
- Time the file system was last checked
- Maximum time between checks
- Default user & group ID for reserved blocks
- Inodes
- Inodes contain file metadata:
- File mode
- User ID (uid)
- Group ID (gid)
- File size, in bytes
- Last file access time (atime)
- Inode change time (ctime)
- Last file modification time (mtime)
- Deletion time (dtime)
- Link count
- Block count
- File type
- File attributes
- List of block addresses, each of which may to:
- A block containing raw file data (direct address)
- An indirect block containing direct addresses (indirect address)
- A doubly-indirect block containing indirect addresses (doubly-indirect address)
- A triply-indirect block containing doubly-indirect addresses (triply-indirect address)
- Directories
- Represented as a list of directory entries, each of which contains an inode number and a filename.
- Files
-
- Regular files
- Represented as a list of blocks, pointers for which go into indirect nodes. Blocks are headerless and contain raw data.
- Links
- Hard links
- Symbolic links
- Special files
-
- Block devices
- Character devices
- FIFOs