sounds dirty, don’t it? here’s how dirty:
One of the most noticeable features of NILFS is that it can “continuously and automatically save instantaneous states of the file system without interrupting service”. NILFS refers to these as checkpoints. In contrast, other file systems such as ZFS, can provide snapshots but they have to suspend operation to perform the snapshot operation. NILFS doesn’t have to do this. The snapshots (checkpoints) are part of the file system design itself.
One of the really cool features of NILFS is that these checkpoints can actually be mounted along side the primary file system. This has many, many uses, one of which is to mount a checkpoint to recover files that were unintentionally erased.
In addition to being able to recover recently erased files and extremely fast crash recovery times, there are a number of other features of NILFS that are very attractive:
* The file size and inode numbers are stored as 64-bit fields
* File sizes of up to 8 EiB (Exbibyte - approximately an Exabyte)
* Block sizes that are smaller than a page size (i.e. 1KB-2KB). This can potentially make NILFS much faster for small files than other file systems.
* File and inode blocks use a B-tree (the use of B-trees in a log-structured file system stems from the implementation which use something called segments)
* NILFS uses 32-bit checksums (CRC32) on data and metadata for integrity assurance
* Correctly ordered data and meta-data writes
* Redundant superblock
* Read-ahead for meta data files as well as data files (helps read performance)
* Continuous check pointing which can be used for snapshots. These can be used for backups or they can even be used for recovering files.
