NILFS

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article may need to be rewritten to comply with Wikipedia's quality standards. You can help. The talk page may contain suggestions. (September 2013) This article contains content that is written like an advertisement. Please help improve it by removing promotional content and inappropriate external links, and by adding encyclopedic content written from a neutral point of view. (September 2013) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

NILFS or NILFS2 (New Implementation of a Log-structured File System) is a

"NILFS is a log-structured file system, in that the storage medium is treated like a circular buffer and new blocks are always written to the end.[…]Log-structured file systems are often used for flash media since they will naturally perform wear-leveling;[…]NILFS emphasizes snapshots. The log-structured approach is a specific form of copy-on-write behavior, so it naturally lends itself to the creation of file system snapshots. The NILFS developers talk about the creation of "continuous snapshots" which can be used to recover from user-initiated file system problems[…]."[2]

Using a

Some file systems, like

# inspect /dev/sda2
...
nilfs> listcp
   1     6 Tue Jul 12 14:55:57 2005 MajorCP|LogiBegin|LogiEnd
2048  2352 Tue Jul 12 14:55:58 2005 MajorCP|LogiEnd
...
nilfs> quit

# mount -t nilfs -r -o cp=2048 /dev/sda2 /nilfs-cp
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             70332412   8044540  62283776  12% /nilfs
/dev/sda2             70332412   8044540  62283776  12% /nilfs-cp

Continuous snapshotting is not provided by most file systems, including those supporting point-in-time snapshotting (e.g. Btrfs)

NILFS creates a number of checkpoints every few seconds or per synchronous write basis (unless there is no change). Users can select significant versions among continuously created checkpoints, and can change them into snapshots which will be preserved until they are changed back to checkpoints.

There is no limit on the number of snapshots until the volume gets full. Each snapshot is mountable as a read-only file system. It is mountable concurrently with a writable mount and other snapshots, and this feature is convenient to make consistent backups during use.

Possible uses of NILFS include versioning, tamper detection,

The current major version of NILFS is version 2, which is referred to as NILFS2. NILFS2 implements online garbage collection to reclaim disk space with keeping multiple snapshots.

Other NILFS features include:

• B-tree based file and inode management.
• Immediate recovery after system crash.
• 64-bit data structures; support many files, large files and disks.
• 64-bit on-disk timestamps which are free of the year 2038 problem.

Current status

Issues

As of 2023, NILFS lacks a dedicated consistency checking utility (fsck), and thus can't recover from severe errors that cause it to fail to find a valid checkpoint. ^{[4] [5]}

Supported features

• Basic POSIX file system features
• Snapshots
  • Automatically and continuously taken
  • No limit on the number of snapshots until the volume gets full
  • Mountable as read-only file systems
  • Mountable concurrently with the writable mount (convenient to make consistent backups during use)
  • Quick listing
• Background Garbage Collection (GC)
  • Can maintain multiple snapshots
  • Selectable GC Policy, which is given by a userland daemon.
• Quick crash recovery on-mount
• Read-ahead for meta data files as well as data files
• Block sizes smaller than page size (e.g. 1KB
  or 2KB)
• Online resizing (since Linux-3.x and nilfs-utils 2.1)
• Related utilities (by contribution of Jiro SEKIBA)
  • grub2
  • blkid
    , libblkid, uuid mount)
  • udisks
    , palimpsest
  • File system label (nilfs-tune)

Additional features

• Fast write and recovery times
• Minimal damage to file data and system consistency on hardware failure
  • 32-bit
    CRC32) on data and metadata for integrity assurance (per block group, in segment summary) ^[6][7]
  • Correctly ordered data and meta-data writes
  • Redundant superblock
• Internal data is processed in 64-bit wide word size
• Can create and store huge files (8
  EiB
  )

Compatibility

NILFS is available in various

It is also supported by partition-editing application like GParted.^[11]

A separate,

If you've got a workload that's latency sensitive, you might want to use NILFS. If you've got one that's throughput sensitive, you might want to use F2FS.

— Peter Chubb

NILFS2 works much better for the lots of small files case than F2FS or EXT4.

— Peter Chubb

License

The NILFS2 file system utilities are made available under the GNU Public License version 2, with the exception of the lib/nilfs libraries and their header files, which are made available under the GNU Lesser General Public License Version 2.1.

Developers

The Japanese primary authors and major contributors to the nilfs-utils who worked or are working at labs of NTT Corporation are:

• Ryusuke Konishi (Primary maintainer, 02/2008–Present)
• Koji Sato
• Naruhiko Kamimura
• Seiji Kihara
• Yoshiji Amagai
• Hisashi Hifumi and
• Satoshi Moriai.

Other major contributors are:

• Andreas Rohner ^[14]
• Dan McGee
• David Arendt
• David Smid
• dexen deVries
• Dmitry Smirnov
• Eric Sandeen
• Jiro SEKIBA
• Matteo Frigo
• Hitoshi Mitake
• Takashi Iwai
• Vyacheslav Dubeyko

See also

• ZFS
• Btrfs
• F2FS, another log-structured file system implementation
• List of file systems
• Comparison of file systems
• Log-structured File System (BSD)
• Sprite operating system

References

External links

• Official website
• "An Article Describing High-level Features". Archived from the original on 2013-01-03.
• "World's Largest TELCO Joins Open Source Development Labs". Archived from the original on 2013-01-27.
• NILFS: A File System to Make SSDs Scream^[usurped]
• Manjaro tutorial NILFS: A filesystem designed to minimize the likelyhood [sic] of data loss Archived 2017-01-06 at the Wayback Machine