In ext2, there is a mechanism for reserving a certain number of blocksfor a particular user (normally the super-user).  This is intended toallow for the system to continue functioning even if non-priveleged usersfill up all the space available to them (this is independent of filesystemquotas).  It also keeps the filesystem from filling up entirely whichhelps combat fragmentation.Filesystem check----------------At boot time, most systems run a consistency check (e2fsck) on theirfilesystems.  The superblock of the ext2 filesystem contains severalfields which indicate whether fsck should actually run (since checkingthe filesystem at boot can take a long time if it is large).  fsck willrun if the filesystem was not cleanly unmounted, if the maximum mountcount has been exceeded or if the maximum time between checks has beenexceeded.Feature Compatibility---------------------The compatibility feature mechanism used in ext2 is sophisticated.It safely allows features to be added to the filesystem, withoutunnecessarily sacrificing compatibility with older versions of thefilesystem code.  The feature compatibility mechanism is not supported bythe original revision 0 (EXT2_GOOD_OLD_REV) of ext2, but was introduced inrevision 1.  There are three 32-bit fields, one for compatible features(COMPAT), one for read-only compatible (RO_COMPAT) features and one forincompatible (INCOMPAT) features.These feature flags have specific meanings for the kernel as follows:A COMPAT flag indicates that a feature is present in the filesystem,but the on-disk format is 100% compatible with older on-disk formats, soa kernel which didn't know anything about this feature could read/writethe filesystem without any chance of corrupting the filesystem (or evenmaking it inconsistent).  This is essentially just a flag which says"this filesystem has a (hidden) feature" that the kernel or e2fsck maywant to be aware of (more on e2fsck and feature flags later).  The ext3HAS_JOURNAL feature is a COMPAT flag because the ext3 journal is simplya regular file with data blocks in it so the kernel does not need totake any special notice of it if it doesn't understand ext3 journaling.An RO_COMPAT flag indicates that the on-disk format is 100% compatiblewith older on-disk formats for reading (i.e. the feature does not changethe visible on-disk format).  However, an old kernel writing to such afilesystem would/could corrupt the filesystem, so this is prevented. Themost common such feature, SPARSE_SUPER, is an RO_COMPAT feature becausesparse groups allow file data blocks where superblock/group descriptorbackups used to live, and ext2_free_blocks() refuses to free these blocks,which would leading to inconsistent bitmaps.  An old kernel would alsoget an error if it tried to free a series of blocks which crossed a groupboundary, but this is a legitimate layout in a SPARSE_SUPER filesystem.An INCOMPAT flag indicates the on-disk format has changed in someway that makes it unreadable by older kernels, or would otherwisecause a problem if an old kernel tried to mount it.  FILETYPE is anINCOMPAT flag because older kernels would think a filename was longerthan 256 characters, which would lead to corrupt directory listings.The COMPRESSION flag is an obvious INCOMPAT flag - if the kerneldoesn't understand compression, you would just get garbage back fromread() instead of it automatically decompressing your data.  The ext3RECOVER flag is needed to prevent a kernel which does not understand theext3 journal from mounting the filesystem without replaying the journal.For e2fsck, it needs to be more strict with the handling of theseflags than the kernel.  If it doesn't understand ANY of the COMPAT,RO_COMPAT, or INCOMPAT flags it will refuse to check the filesystem,because it has no way of verifying whether a given feature is validor not.  Allowing e2fsck to succeed on a filesystem with an unknownfeature is a false sense of security for the user.  Refusing to checka filesystem with unknown features is a good incentive for the user toupdate to the latest e2fsck.  This also means that anyone adding featureflags to ext2 also needs to update e2fsck to verify these features.Metadata--------It is frequently claimed that the ext2 implementation of writingasynchronous metadata is faster than the ffs synchronous metadatascheme but less reliable.  Both methods are equally resolvable by theirrespective fsck programs.If you're exceptionally paranoid, there are 3 ways of making metadatawrites synchronous on ext2:per-file if you have the program source: use the O_SYNC flag to open()per-file if you don't have the source: use "chattr +S" on the fileper-filesystem: add the "sync" option to mount (or in /etc/fstab)the first and last are not ext2 specific but do force the metadata tobe written synchronously.  See also Journaling below.Limitations-----------There are various limits imposed by the on-disk layout of ext2.  Otherlimits are imposed by the current implementation of the kernel code.Many of the limits are determined at the time the filesystem is firstcreated, and depend upon the block size chosen.  The ratio of inodes todata blocks is fixed at filesystem creation time, so the only way toincrease the number of inodes is to increase the size of the filesystem.No tools currently exist which can change the ratio of inodes to blocks.Most of these limits could be overcome with slight changes in the on-diskformat and using a compatibility flag to signal the format change (atthe expense of some compatibility).Filesystem block size:     1kB        2kB        4kB        8kBFile size limit:          16GB      256GB     2048GB     2048GBFilesystem size limit:  2047GB     8192GB    16384GB    32768GBThere is a 2.4 kernel limit of 2048GB for a single block device, so nofilesystem larger than that can be created at this time.  There is alsoan upper limit on the block size imposed by the page size of the kernel,so 8kB blocks are only allowed on Alpha systems (and other architectureswhich support larger pages).There is an upper limit of 32768 subdirectories in a single directory.There is a "soft" upper limit of about 10-15k files in a single directorywith the current linear linked-list directory implementation.  This limitstems from performance problems when creating and deleting (and alsofinding) files in such large directories.  Using a hashed directory index(under development) allows 100k-1M+ files in a single directory withoutperformance problems (although RAM size becomes an issue at this point).The (meaningless) absolute upper limit of files in a single directory(imposed by the file size, the realistic limit is obviously much less)is over 130 trillion files.  It would be higher except there are notenough 4-character names to make up unique directory entries, so theyhave to be 8 character filenames, even then we are fairly close torunning out of unique filenames.Journaling----------A journaling extension to the ext2 code has been developed by StephenTweedie.  It avoids the risks of metadata corruption and the need towait for e2fsck to complete after a crash, without requiring a changeto the on-disk ext2 layout.  In a nutshell, the journal is a regularfile which stores whole metadata (and optionally data) blocks that havebeen modified, prior to writing them into the filesystem.  This meansit is possible to add a journal to an existing ext2 filesystem withoutthe need for data conversion.When changes to the filesystem (e.g. a file is renamed) they are stored ina transaction in the journal and can either be complete or incomplete atthe time of a crash.  If a transaction is complete at the time of a crash(or in the normal case where the system does not crash), then any blocksin that transaction are guaranteed to represent a valid filesystem state,and are copied into the filesystem.  If a transaction is incomplete atthe time of the crash, then there is no guarantee of consistency forthe blocks in that transaction so they are discarded (which means anyfilesystem changes they represent are also lost).The ext3 code is currently (Apr 2001) available for 2.2 kernels only,and not yet available for 2.4 kernels.References==========The kernel source	file:/usr/src/linux/fs/ext2/e2fsprogs (e2fsck)	http://e2fsprogs.sourceforge.net/Design & Implementation	http://e2fsprogs.sourceforge.net/ext2intro.htmlJournaling (ext3)	ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/Hashed Directories	http://kernelnewbies.org/~phillips/htree/Filesystem Resizing	http://ext2resize.sourceforge.net/Extended Attributes &Access Control Lists	http://acl.bestbits.at/Compression (*)		http://www.netspace.net.au/~reiter/e2compr/Implementations for:Windows 95/98/NT/2000	http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htmWindows 95 (*)		http://www.yipton.demon.co.uk/content.html#FSDEXT2DOS client (*)		ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/OS/2			http://perso.wanadoo.fr/matthieu.willm/ext2-os2/RISC OS client		ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/(*) no longer actively developed/supported (as of Apr 2001)