Lines Matching refs:the
6 Theodore Ts'o and Stephen Tweedie, it was a major rewrite of the
7 Extended Filesystem. It is currently still (April 2001) the predominant
9 for NetBSD, FreeBSD, the GNU HURD, Windows 95/98/NT, OS/2 and RISC OS.
14 Most defaults are determined by the filesystem superblock, and can be
26 debug Extra debugging information is sent to the
30 errors=remount-ro Remount the filesystem read-only on an error.
31 errors=panic Panic and halt the machine if an error occurs.
33 grpid, bsdgroups Give objects the same group ID as their parent.
34 nogrpid, sysvgroups New objects have the group ID of their creator.
38 oldalloc Enable the old block allocator. Orlov should
40 feedback if it's the contrary for you.
41 orlov (*) Use the Orlov block allocator.
45 resuid=n The user ID which may use the reserved blocks.
46 resgid=n The group ID which may use the reserved blocks.
69 the concepts of blocks, inodes and directories. It has space in the
79 The space in the device or file is split up into blocks. These are
81 which is decided when the filesystem is created. Smaller blocks mean
83 and also impose other limits on the size of files and the filesystem.
89 and minimise the amount of head seeking when reading a large amount
91 descriptor table stored in the block(s) immediately after the superblock.
92 Two blocks near the start of each group are reserved for the block usage
93 bitmap and the inode usage bitmap which show which blocks and inodes
95 that the maximum size of a block group is 8 times the size of a block.
97 The block(s) following the bitmaps in each block group are designated
98 as the inode table for that block group and the remainder are the data
100 in the same block group as the inode which contains them.
105 The superblock contains all the information about the configuration of
106 the filing system. The primary copy of the superblock is stored at an
107 offset of 1024 bytes from the start of the device, and it is essential
108 to mounting the filesystem. Since it is so important, backup copies of
109 the superblock are stored in block groups throughout the filesystem.
110 The first version of ext2 (revision 0) stores a copy at the start of
111 every block group, along with backups of the group descriptor block(s).
113 filesystems, later revisions can optionally reduce the number of backup
114 copies by only putting backups in specific groups (this is the sparse
117 The information in the superblock contains fields such as the total
118 number of inodes and blocks in the filesystem and how many are free,
119 how many inodes and blocks are in each block group, when the filesystem
121 what version of the filesystem it is (see the Revisions section below)
124 If the filesystem is revision 1 or higher, then there are extra fields,
125 such as a volume name, a unique identification number, the inode size,
128 All fields in the superblock (as in all other ext2 structures) are stored
129 on the disc in little endian format, so a filesystem is portable between
135 The inode (index node) is a fundamental concept in the ext2 filesystem.
136 Each object in the filesystem is represented by an inode. The inode
137 structure contains pointers to the filesystem blocks which contain the
138 data held in the object and all of the metadata about an object except
139 its name. The metadata about an object includes the permissions, owner,
144 There are some reserved fields which are currently unused in the inode
145 structure and several which are overloaded. One field is reserved for the
146 directory ACL if the inode is a directory and alternately for the top 32
147 bits of the file size if the inode is a regular file (allowing file sizes
149 by the HURD to reference the inode of a program which will be used to
150 interpret this object. Most of the remaining reserved fields have been
151 used up for both Linux and the HURD for larger owner and group fields,
152 The HURD also has a larger mode field so it uses another of the remaining
153 fields to store the extra more bits.
155 There are pointers to the first 12 blocks which contain the file's data
156 in the inode. There is a pointer to an indirect block (which contains
157 pointers to the next set of blocks), a pointer to a doubly-indirect
162 for by the standard chmod flags. These flags can be listed with lsattr
163 and changed with the chattr command, and allow specific filesystem
174 each name with an inode number. Later revisions of the filesystem also
175 encode the type of the object (file, directory, symlink, device, fifo,
176 socket) to avoid the need to check the inode itself for this information
180 The inode allocation code tries to assign inodes which are in the same
181 block group as the directory in which they are first created.
184 the filenames in the directory; a pending enhancement uses hashing of the
185 filenames to allow lookup without the need to scan the entire directory.
194 special mention because the data for them is stored within the inode
195 itself if the symlink is less than 60 bytes long. It uses the fields
196 which would normally be used to store the pointers to data blocks.
198 block for the symlink, and most symlinks are less than 60 characters long.
201 them. Instead, their device number is stored in the inode, again reusing
202 the fields which would be used to point to the data blocks.
208 for a particular user (normally the super-user). This is intended to
209 allow for the system to continue functioning even if non-privileged users
210 fill up all the space available to them (this is independent of filesystem
211 quotas). It also keeps the filesystem from filling up entirely which
218 filesystems. The superblock of the ext2 filesystem contains several
220 the filesystem at boot can take a long time if it is large). fsck will
221 run if the filesystem was not cleanly unmounted, if the maximum mount
222 count has been exceeded or if the maximum time between checks has been
229 It safely allows features to be added to the filesystem, without
230 unnecessarily sacrificing compatibility with older versions of the
232 the original revision 0 (EXT2_GOOD_OLD_REV) of ext2, but was introduced in
237 These feature flags have specific meanings for the kernel as follows:
239 A COMPAT flag indicates that a feature is present in the filesystem,
240 but the on-disk format is 100% compatible with older on-disk formats, so
242 the filesystem without any chance of corrupting the filesystem (or even
244 "this filesystem has a (hidden) feature" that the kernel or e2fsck may
246 HAS_JOURNAL feature is a COMPAT flag because the ext3 journal is simply
247 a regular file with data blocks in it so the kernel does not need to
250 An RO_COMPAT flag indicates that the on-disk format is 100% compatible
251 with older on-disk formats for reading (i.e. the feature does not change
252 the visible on-disk format). However, an old kernel writing to such a
253 filesystem would/could corrupt the filesystem, so this is prevented. The
261 An INCOMPAT flag indicates the on-disk format has changed in some
266 The COMPRESSION flag is an obvious INCOMPAT flag - if the kernel
269 RECOVER flag is needed to prevent a kernel which does not understand the
270 ext3 journal from mounting the filesystem without replaying the journal.
272 For e2fsck, it needs to be more strict with the handling of these
273 flags than the kernel. If it doesn't understand ANY of the COMPAT,
274 RO_COMPAT, or INCOMPAT flags it will refuse to check the filesystem,
277 feature is a false sense of security for the user. Refusing to check
278 a filesystem with unknown features is a good incentive for the user to
279 update to the latest e2fsck. This also means that anyone adding feature
285 It is frequently claimed that the ext2 implementation of writing
286 asynchronous metadata is faster than the ffs synchronous metadata
293 per-file if you have the program source: use the O_SYNC flag to open()
294 per-file if you don't have the source: use "chattr +S" on the file
295 per-filesystem: add the "sync" option to mount (or in /etc/fstab)
297 the first and last are not ext2 specific but do force the metadata to
303 There are various limits imposed by the on-disk layout of ext2. Other
304 limits are imposed by the current implementation of the kernel code.
305 Many of the limits are determined at the time the filesystem is first
306 created, and depend upon the block size chosen. The ratio of inodes to
307 data blocks is fixed at filesystem creation time, so the only way to
308 increase the number of inodes is to increase the size of the filesystem.
309 No tools currently exist which can change the ratio of inodes to blocks.
311 Most of these limits could be overcome with slight changes in the on-disk
312 format and using a compatibility flag to signal the format change (at
313 the expense of some compatibility).
322 an upper limit on the block size imposed by the page size of the kernel,
329 with the current linear linked-list directory implementation. This limit
336 (imposed by the file size, the realistic limit is obviously much less)
345 A journaling extension to the ext2 code has been developed by Stephen
346 Tweedie. It avoids the risks of metadata corruption and the need to
348 to the on-disk ext2 layout. In a nutshell, the journal is a regular
350 been modified, prior to writing them into the filesystem. This means
352 the need for data conversion.
354 When changes to the filesystem (e.g. a file is renamed) they are stored in
355 a transaction in the journal and can either be complete or incomplete at
356 the time of a crash. If a transaction is complete at the time of a crash
357 (or in the normal case where the system does not crash), then any blocks
359 and are copied into the filesystem. If a transaction is incomplete at
360 the time of the crash, then there is no guarantee of consistency for
361 the blocks in that transaction so they are discarded (which means any