Hubbry Logo
NILFSNILFSMain
Open search
NILFS
Community hub
NILFS
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
NILFS
NILFS
NILFS
View on Wikipedia
from Wikipedia
NILFS
Developer(s)Nippon Telegraph and Telephone Cyber Space Laboratories
Full nameNew Implementation of a Log-structured File System
Introduced2005; 21 years ago (2005) with Linux kernel 2.6.13
Structures
File allocationB-tree
Limits
Max volume size8 EiB
Max file size8 EiB
Max filename length255 bytes
Features
Dates recordedatime (planned)
Date resolution64-bit on-disk timestamps
AttributesPOSIX, with plans for extended attributes
File system
permissions		POSIX, with plans for ACLs[1]
Transparent
compression		No
Transparent
encryption		No
Copy-on-writeYes
Other
Supported
operating systems		Linux kernel, (ReadOnly for NetBSD)

NILFS or NILFS2 (New Implementation of a Log-structured File System) is a log-structured file system implementation for the Linux kernel. It was developed by Nippon Telegraph and Telephone Corporation (NTT) CyberSpace Laboratories and a community from all over the world. NILFS was released under the terms of the GNU General Public License (GPL).

Design

[edit]

"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 copy-on-write technique known as a log-structured file system, NILFS records all data in a continuous log-like format that is only appended to, never overwritten, an approach that is designed to reduce seek times, as well as minimize the kind of data loss that occurs after a crash with conventional file systems. For example, data loss occurs on ext3 file systems when the system crashes during a write operation. When the system reboots, the journal notes that the write did not complete, and any partial data writes are lost.

Some file systems, like UFS-derived file systems used by the Solaris operating system and BSDs, provide a snapshot feature that prevents[citation needed] such data loss, but the snapshot configuration can be lengthy on large file systems. NILFS, in contrast, can "continuously and automatically [save] instantaneous states of the file system without interrupting service", according to NTT Labs.[3]

The "instantaneous states" that NILFS continuously saves can actually be mounted, read-only, at the same time that the actual file system is mounted read-write — a capability useful for data recovery after hardware failures and other system crashes. The "lscp" (list checkpoint) command of an interactive NILFS "inspect" utility is first used to find the checkpoint's address, in this case "2048": 

# 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

The checkpoint address is then used to mount the checkpoint: 

# 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

Features

[edit]

NILFS provides continuous snapshotting. In addition to the versioning capability of the entire file system, users can even restore files mistakenly overwritten or deleted at any recent time. Since NILFS can keep consistency like conventional LFS, it achieves quick recovery after system crashes.

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 for making consistent backups during use.

Possible uses of NILFS include versioning, tamper detection, SOX compliance logging, data loss recovery.

The current major version of NILFS is version 2, referred to as NILFS2. NILFS2 implements online garbage collection to reclaim disk space while 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

[edit]

Issues

[edit]

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

[edit]
  • 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. 1 KB or 2 KB)
  • Online resizing (since Linux-3.x and nilfs-utils 2.1)
  • Related utilities (by contribution of Jiro SEKIBA)

Additional features

[edit]
  • Fast write and recovery times
  • Minimal damage to file data and system consistency on hardware failure
  • Internal data is processed in 64-bit wide word size
  • Can create and store huge files (8 EiB)

Compatibility

[edit]

NILFS is available in various GNU/Linux distributions like Arch Linux,[8] Debian[9] (since version 5.0), Fedora, Gentoo,[10] Linux Mint, NixOS, Ubuntu (since version 9.10), etc. To use it, users typically need to install the nilfs-utils or nilfs-tools package. A boot-cd with NILFS is also available on PrRescue.

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

A separate, BSD licensed implementation, currently with read-only support, is included in NetBSD.[12]

Relative performance

[edit]

In the January 2015 presentation SD cards and file systems for embedded systems at Linux.conf.au, it was stated:[13]

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

[edit]

The NILFS2 file system utilities are made available under the GNU General 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

[edit]

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

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

NILFS

View on Grokipedia
from Grokipedia
NILFS2 (New Implementation of a version 2) is a designed for the , enabling continuous snapshotting of the to support versioning and rapid recovery from crashes or data overwrites. It creates checkpoints at regular intervals—typically every few seconds or per synchronous write—allowing users to access and restore previous states of files without filling the storage volume until capacity is reached. Developed by Corporation (NTT) Laboratories, NILFS2 combines the crash consistency of traditional with the quick recovery benefits of journaling systems, making it suitable for environments requiring and historical access. NILFS originated as an open-source under the GNU General Public License, with its initial implementation focused on addressing limitations in earlier log-structured file systems like scalability and garbage collection efficiency. The evolved to NILFS2, which introduced online garbage collection to manage disk space dynamically without interrupting operations, along with support for 64-bit addressing to handle large volumes and files. It has been integrated into the mainline since version 2.6.30 in 2009, with ongoing maintenance through kernel updates and user-space tools like nilfs-utils for formatting, mounting, and snapshot management. In November 2025, a second maintainer, Viacheslav Dubeyko, was added, indicating renewed interest in the . Key features of NILFS2 include the ability to mount unlimited read-only snapshots alongside the active writable , facilitating applications such as tamper detection, (e.g., ), and seamless file recovery from deletions or modifications that occurred seconds earlier. Unlike conventional s, it appends all modifications sequentially in logs rather than overwriting in place, which minimizes fragmentation and enhances performance on flash storage or high-write workloads. However, it currently lacks support for features like access time updates (atime), extended attributes, ACLs, quotas, and checks (), positioning it as a specialized choice for versioning-focused use cases rather than general-purpose deployments. NILFS2's design avoids the through 64-bit time structures and supports online resizing of volumes, enhancing its adaptability for modern storage needs. The daemon nilfs_cleanerd handles background garbage collection to reclaim space from obsolete checkpoints, ensuring sustained performance over time. As of September 2025, the latest release of nilfs-utils (version 2.2.12) includes fixes for stability issues, underscoring the project's active development for environments.

Introduction

Overview

NILFS2 (New Implementation of a Log-structured File System version 2) is a designed for the , developed by (NTT) Corporation's Cyber Space Laboratories. It appends all modifications sequentially to the disk in a continuous log, enabling efficient management of filesystem updates without the fragmentation issues common in traditional in-place update systems. The primary purpose of NILFS2 is to provide continuous snapshotting and versioning capabilities, allowing users to restore overwritten or deleted files, or even the entire filesystem state, to any point in the past. This versioning ensures that the filesystem maintains a history of changes through automatically generated checkpoints, facilitating recovery from errors or accidental modifications without manual intervention. NILFS2 offers key advantages such as crash recovery in seconds—limited to replaying only the most recent log segment—resulting in minimal data loss compared to traditional filesystems like or , which may require longer journaling or operations. Additionally, it supports unlimited snapshots that persist until storage capacity is exhausted, mountable as read-only instances for backup or auditing purposes. Development of NILFS began with its initial release in September 2005, followed by the open-source launch of NILFS2 in June 2007, and its integration into the mainline with version 2.6.30 in June 2009, marking the first filesystem from to achieve this milestone.

History

NILFS was developed by (NTT) Corporation's Cyber Space Laboratories as a research project beginning in 2005, aimed at implementing advanced (LFS) features within the Linux kernel to enhance data reliability and recovery capabilities. The initial prototype, known as NILFS version 1, was released as open-source software in September 2005 under the GNU General Public License version 2.0. This early version focused on continuous snapshotting to prevent data loss in enterprise Linux environments. A major milestone came with the release of NILFS2 in June 2007, which introduced improved snapshot management mechanisms for better versioning and space efficiency. NILFS2 was subsequently upstreamed into the mainline Linux kernel as version 2.6.30 in June 2009, marking the first file system originating from Japan to be integrated into the kernel. Further enhancements included the addition of online resizing capabilities, enabled in version 3.0 (released December 2011) alongside nilfs-utils version 2.1 (stable release November 2011), allowing dynamic volume expansion or shrinkage without unmounting. Development activity slowed significantly after , with only sporadic bug fixes and minor updates, fostering perceptions of project abandonment among the community. This dormancy persisted until 2024, when a series of fixes addressing issues like potential deadlocks and buffer access errors were merged into 6.12. Renewed interest emerged in late 2025, highlighted by the announcement on November 8, 2025, of Viacheslav Dubeyko as a second maintainer alongside Ryusuke Konishi, updating the kernel's MAINTAINERS file to reflect co-maintenance status. This development signals potential for future enhancements, such as optimizations to garbage collection processes.

Design Principles

Log-Structured Architecture

NILFS employs a (LFS) architecture, treating the storage device as a continuous, circular log buffer where all file system modifications—both data and metadata—are appended sequentially rather than updated in place. This approach utilizes (COW) semantics, ensuring that existing data blocks remain unchanged while new versions are written to fresh locations in the log, thereby preserving previous states and enabling efficient versioning. By appending updates in a log-like manner, NILFS avoids the fragmentation and seek overhead associated with random writes in traditional s. The divides the storage into fixed-size segments, typically 8 MB each, which serve as the fundamental units for and garbage collection. Each segment consists of blocks containing actual or metadata and summary blocks that record the organization of these payloads, including file information (finfo) and block information (binfo) structures to facilitate recovery and . File and directory contents are organized using structures: inodes are managed via B-trees rooted in the superblock, while file blocks use B-trees rooted in their respective inodes, supporting efficient lookups and . Additionally, NILFS incorporates 64-bit addressing to handle large volumes, with virtual block addressing achieved through a dedicated Data Address Translation (DAT) file that maps logical to physical locations. This LFS design yields significant benefits, including minimized disk seeks through sequential appends, which substantially improves write throughput—particularly for synchronous operations—and ensures the atomicity of updates by grouping them into complete segments. The continuous logging mechanism also enhances crash recovery, as the file system can be reconstructed from the log without extensive scanning. Unlike journaling file systems such as ext4, which selectively log metadata or data in a separate journal for recovery, NILFS logs all changes continuously across the entire volume, integrating versioning directly into the core architecture rather than as an add-on feature.

Checkpointing and Versioning

NILFS employs checkpointing as a core mechanism to capture atomic, consistent states of the filesystem at regular intervals, serving as the foundation for its versioning capabilities. Checkpoints represent periodic points in the log-structured sequence where all modified data and metadata blocks are fully written to disk, ensuring a complete and recoverable filesystem image without partial updates. These checkpoints are generated automatically every few seconds or upon synchronous write operations, provided there are changes to the filesystem, and are sequentially numbered for identification, such as checkpoint #2048. This integrates with the log-structured appends, where ongoing writes accumulate until a checkpoint finalizes the segment. Checkpoints can be converted to snapshots by marking them as protected, preventing garbage collection and preserving them indefinitely until space management requires otherwise. The versioning process in NILFS leverages these checkpoints to enable full filesystem versioning, allowing multiple historical states to coexist on the same volume without overwriting prior data. Each checkpoint defines a distinct version of the entire filesystem, including all files, directories, and metadata, which can be accessed independently. Users mount specific checkpoints in read-only mode using the mount option cp=<checkpoint_number>, such as mount -t nilfs2 -r -o cp=2048 /dev/sda1 /mnt/version, enabling concurrent access alongside the active writable mount of the current checkpoint. This facilitates features like online backups or forensic analysis of past states without interrupting operations. There is no inherent limit to the number of checkpoints or versions retained, as they persist until disk space is exhausted, with management handled through filesystem-internal mechanisms. For recovery, NILFS relies on the latest valid checkpoint to restore consistency after a crash or power failure, achieving near-instantaneous replay without extensive scanning of the log. The system identifies the most recent checkpoint containing a valid super root block, which encapsulates the root of the filesystem structure, and replays only the necessary atomic segments to bring the mount to that state. validation on log segments ensures the integrity of this process, minimizing to the interval since the last checkpoint. Current implementations maintain snapshots as read-only.

Core Features

Snapshotting Capabilities

NILFS supports continuous snapshotting through its automatic checkpoint mechanism, where read-only snapshots are created at regular intervals, typically every few seconds to tens of seconds during file system operations. These snapshots capture the state of the entire file system, enabling users to restore overwritten or deleted files to their condition from mere seconds prior without interrupting ongoing writes. This feature stems from the log-structured design, where each checkpoint represents a consistent, versioned view of the file system that can be selectively promoted to a persistent snapshot. Practical use cases for NILFS snapshots include data protection and recovery, such as restoring accidentally deleted or overwritten files to previous states, which provides versioning benefits for file integrity and tamper detection. In backup scenarios, snapshots facilitate online, incremental copies by allowing read-only mounts alongside the active writable , minimizing and enabling efficient data replication without quiescing the system. For and compliance, such as SOX logging, snapshots allow reversion to prior versions, preserving historical states for analysis or audit trails. Snapshots in NILFS offer mounting flexibility, permitting multiple concurrent read-only mounts of different snapshots on the same without impacting the of the writable mount or reads from the snapshots themselves. Users mount a specific snapshot using options like -r -o cp=<checkpoint_number>, providing direct access to historical data as if it were a separate . There is no inherent limit to the number of snapshots, constrained only by available disk space. Advanced management includes policy-based snapshot retention, configured via the protection_period parameter in /etc/nilfs_cleanerd.conf, which specifies the minimum age (in seconds) before a snapshot or checkpoint becomes eligible for garbage collection, ensuring critical versions are preserved as needed.

Garbage Collection and Maintenance

NILFS employs an online garbage collection mechanism to reclaim disk space by identifying and removing obsolete log segments associated with deleted checkpoints. The process is managed by the background daemon nilfs_cleanerd, which operates continuously on mounted file systems without requiring unmounting, ensuring uninterrupted access to data and snapshots. This daemon uses kernel ioctls, such as NILFS_IOCTL_CLEAN_SEGMENTS, to perform cleanup operations, focusing on segments that contain outdated versions of files generated during the file system's log-structured writes. The garbage collection process divides log segments into hot (actively modified) and cold (obsolete or infrequently accessed) categories based on usage patterns, allowing the daemon to prioritize reclamation of cold segments. During cleanup, valid data blocks from these obsolete segments are copied to new, clean segments, after which the old segments are freed, thereby maintaining the integrity of active snapshots and checkpoints. The behavior is configurable through the nilfs_cleanerd.conf file, which supports policies like the timestamp-based selection of segments (processing from oldest to newest) and parameters such as cleanup intervals (defaulting to 5 seconds, or 1 second when clean segments are low) and segment allocation limits (e.g., minimum and maximum clean segments set to 10% and 20% of disk capacity, respectively). Space management in NILFS ensures reliable operation by triggering prioritized garbage collection when free space falls below configurable thresholds, such as the minimum number of clean segments, preventing the file system from filling up and halting writes. Additionally, NILFS supports the FITRIM operation via the discard mount option, which notifies the underlying storage device (e.g., SSDs) of freed blocks to enable wear-leveling and optimize thin provisioning. Online resizing is integrated with garbage collection through ioctls like NILFS_IOCTL_RESIZE and NILFS_IOCTL_SET_ALLOC_RANGE, allowing dynamic adjustment of the file system's volume size while the cleaner daemon adapts to the new allocation range without downtime.

Implementation

Kernel Integration

NILFS2 has been supported in the Linux kernel since version 2.6.30, when it was merged as the first file system originating from Japan. To enable NILFS2 support during kernel compilation, the configuration option CONFIG_NILFS2_FS must be selected, which builds the nilfs2.ko module or integrates it directly into the kernel. The file system supports block sizes of 1 KB, 2 KB, 4 KB, and 8 KB, with larger sizes up to the system page size also possible depending on the architecture. NILFS2 leverages 64-bit addressing, supporting volume sizes up to approximately 8 exabytes. Mounting a NILFS2 is performed using the standard mount command with the -t nilfs2 option, specifying a block device such as /dev/sda1. The available mount options include barrier (enabled by default) and nobarrier to control write barriers for on storage devices. The cp=n option allows mounting a specific checkpoint (snapshot) as a read-only , where n is the checkpoint number. For synchronous write ordering, order=relaxed (default) or order=strict can be specified to manage how the kernel handles write-back behavior. The discard option enables TRIM support for SSDs to optimize , while nodiscard is the default. Error handling is configurable via errors=remount-ro (default, remounts read-only on errors) or errors=panic (triggers a ). NILFS2 integrates seamlessly with the Linux kernel's subsystem, allowing it to be used on logical volumes managed by LVM or other stacked block devices without requiring additional kernel modules beyond the standard nilfs2 module. It operates on any supported block device, such as /dev/sda or /dev/mapper/vg-lv, treating them as generic storage targets. Recent kernel updates have focused on stability and functionality enhancements for NILFS2. In 6.12, released on November 17, 2024, several fixes were incorporated, including support for common ioctls such as FS_IOC_SETFSLABEL and FS_IOC_GETUUID to enable modern operations. As of November 2025, development continues with the appointment of a new co-maintainer, Viacheslav Dubeyko, to sustain ongoing improvements.

User-Space Utilities

The nilfs-utils package provides essential user-space tools for managing NILFS2 filesystems, including formatting, tuning, and maintenance operations. This package is required to create a new NILFS2 filesystem using mkfs.nilfs2, which formats a block device with the necessary superblock and metadata structures. For tuning filesystem parameters, such as segment size or checkpoint intervals, the nilfs-tune utility serves a role analogous to tune2fs for other filesystems, allowing adjustments to an existing NILFS2 volume. Additionally, the nilfs_cleanerd daemon handles garbage collection by periodically cleaning up obsolete segments to reclaim space, integrating with the kernel's cleaner interface. Key tools in nilfs-utils enable checkpoint management and filesystem resizing. The lscp command lists all checkpoints and snapshots on a NILFS2 device, displaying details like creation time and sequence numbers. Manual checkpoint creation is supported via mkcp, which triggers an immediate checkpoint for versioning purposes. To manage storage, rmcp allows deletion of specific checkpoints, helping to control the number of retained versions and reduce garbage collection overhead. For dynamic volume adjustments, nilfs-resize resizes a mounted NILFS2 filesystem online, supporting both expansion and shrinkage without unmounting. Installation of nilfs-utils is straightforward through distribution repositories; for example, on Debian-based systems, it is available as the nilfs-tools package via apt install nilfs-tools. Source builds require dependencies like libuuid-devel and libmount-devel for compilation. NILFS2 filesystems support labels and UUIDs for identification in /etc/fstab, leveraging blkid for reliable mounting. The utilities integrate with standard tools for broader ecosystem compatibility, including util-linux for mount operations, grub2 for NILFS2 root partitions, and udisks for disk management interfaces.

Performance Characteristics

Benchmark Comparisons

Historical benchmarks have shown mixed results for NILFS2 compared to other file systems. In 2009 tests on a Seagate HDD with 2.6.30, NILFS2 underperformed and in the benchmark for small-file operations, achieving 357 transactions per second compared to 's 2777. This reflects the overhead of its log-structured design in certain metadata-intensive workloads at the time. NILFS2 has demonstrated advantages in sequential write throughput, often reaching 200-300 MB/s in IOzone tests on HDDs, comparable to or higher than and due to its continuous logging mechanism, though it trails in random writes for larger blocks. A 2011 study on multiple SSD models (Micron realSSD C300, Samsung 470, OCZ Vertex2, X25-M) under confirmed NILFS2's compatibility with flash storage, outperforming and in small-block random writes while maintaining similar sequential read speeds around 250 MB/s. In more recent 2020 benchmarks on 5.8 with a 9 3900X and Seagate FireCuda 520 NVMe SSD, NILFS2 generally lagged behind , , , and in most tests, including compile times, I/O throughput, and database workloads, highlighting its niche suitability rather than broad superiority. As of November 2025, no major comprehensive benchmarks for NILFS2 have emerged, though the project has seen renewed interest with an additional maintainer, potentially improving future performance. The 2024 updates in version 6.12 included stability fixes for error handling and state management, enhancing reliability in high-I/O scenarios without introducing performance regressions. Key metrics from historical comparisons include:
MetricNILFS2 ExampleComparison (e.g., vs. EXT4)Context/Source
Small-File Creation (transactions/s)357 (PostMark)SlowerHDD, 2009
Random Write Throughput (4KB IOPS)Higher for small blocksBetter than EXT3/EXT4SSD random I/O, 2011
Sequential Write (MB/s)200-300Comparable or higherLog appends on HDD/SSD, 2009
Crash Recovery TimeQuick (seconds via checkpoint)Faster than fsck on large volumesDesign feature
NILFS2's crash recovery is a strength, typically completing in seconds by replaying the final log segment, in contrast to EXT4's which can take minutes to hours on large volumes.

Optimization Factors

NILFS performance can be tuned through several parameters that balance write efficiency, resource usage, and . One key tunable is the relaxed order mount option, which permits modified data blocks to be written to disk without creating a checkpoint when no metadata updates occur, accelerating synchronous writes at the cost of slightly relaxed recovery ordering during filesystem recovery. Segment size, set during filesystem creation with mkfs.nilfs2, defaults to 2048 blocks (8 MB assuming 4 KB block size) but can be adjusted based on workload; larger segments reduce commit frequency and metadata overhead for sequential write-heavy tasks, while smaller ones suit patterns by minimizing . The garbage collection (GC) interval, configurable via the nilfs_cleanerd daemon in /etc/nilfs_cleanerd.conf, defaults to 5 seconds between cleaning steps but can be increased to lower CPU usage during idle periods, trading off against potential space reclamation delays. Best practices for optimizing NILFS include enabling the discard mount option on SSDs to issue TRIM commands when blocks are freed, enhancing wear leveling and longevity without significant runtime overhead. Barriers should remain enabled (the default) to ensure proper write ordering for data integrity, particularly on journaling devices, though disabling them via the nobarrier option may yield minor speedups on safe hardware at the risk of corruption after power loss. Administrators should monitor free space levels using tools like df to preempt GC stalls, as low space triggers aggressive cleaning that can temporarily elevate CPU and I/O loads. NILFS is particularly suited to write-intensive workloads requiring versioning, such as or system logs, where its continuous checkpointing minimizes and supports efficient recovery without full backups. However, it performs less optimally in read-dominated environments without active snapshot usage, as the log-structured design incurs higher latency for random reads compared to traditional filesystems. Trade-offs include elevated metadata overhead from perpetual logging, which amplifies on flash media, and periodic CPU spikes from GC during sustained high-write activity, potentially requiring tuning of cleanerd parameters like max_clean_segments (default 20% of total) to cap reclamation bursts. In benchmark comparisons with other filesystems, these optimizations highlight NILFS's strengths in snapshot-enabled scenarios.

Compatibility and Limitations

Platform Support

NILFS2 provides full read/write support on kernels starting from version 2.6.30, where it was merged into the mainline kernel. This integration allows seamless use as a native on standard block devices. On , NILFS is supported in read-only mode since NetBSD 6, implemented as a cleanroom port without write capabilities. There is no native support for NILFS on Windows or macOS; access typically requires running in a or, if available, mounting via FUSE-based tools, though no dedicated NILFS FUSE implementation exists. NILFS2 is available across major distributions through standard repositories or packages, including , , (via kernel inclusion), (through the nilfs-utils package), and others such as Raspbian (for ), , , , Gentoo, and (with standalone kernel modules for RHEL-based systems). For partitioning, tools such as include NILFS2 as a supported type. In terms of hardware, NILFS2 operates on any block device, including traditional hard disk drives (HDDs) and solid-state drives (SSDs). It is SSD-friendly, featuring support for the discard/TRIM command to optimize performance and longevity on flash storage by notifying the device of unused blocks. While NILFS2 does not natively implement or layering, it is compatible with Logical Volume Manager (LVM) as an underlying volume management layer, allowing NILFS2 volumes to be created on LVM logical volumes. To set up NILFS2, the kernel must be configured with the NILFS_FS option enabled during compilation, which is included by default in most modern distributions. The nilfs-utils package provides essential user-space tools like mkfs.nilfs2 for formatting and mount.nilfs2 for mounting. An example entry in /etc/fstab for automatic mounting is: /dev/sda1 /mnt/nilfs nilfs2 defaults 0 2, where the file system type is specified as nilfs2. After installation, formatting a partition involves running mkfs -t nilfs2 /dev/block_device, followed by mounting with mount -t nilfs2 /dev/block_device /mountpoint.

Unsupported Features

NILFS2 lacks several POSIX-compliant features essential for broader compatibility and advanced functionality. It does not support extended attributes (xattrs), which are used for storing additional metadata such as security labels or user-defined properties. Access Control Lists (ACLs) are also unsupported, limiting fine-grained permission management beyond basic Unix modes. Quota enforcement for users and groups is absent, preventing disk space limits in multi-user environments. Additionally, access time (atime) updates are not implemented, and features like O_TMPFILE for anonymous temporary files and hole-punching via fallocate are unavailable. Maintenance operations in NILFS2 have notable gaps. There is no dedicated fsck utility for offline filesystem checks and repairs, requiring reliance on clean shutdowns to avoid ; in cases of unclean unmounts, recovery depends on mounting snapshots to restore data. Online defragmentation is not supported, potentially leading to fragmentation over time in log-structured writes. Deletion of orphan inodes—files without directory entries but still referenced—remains pending, which can contribute to space inefficiencies until addressed. These omissions may limit NILFS2's use in environments requiring quotas, ACLs, or other advanced features. Workarounds include disabling atime updates via mount options like noatime (though inherently unsupported, this avoids related overhead) and leveraging snapshot-based recovery for maintenance, as detailed in snapshotting documentation. Ongoing development plans, as outlined in project TODO lists updated through , target improvements such as writable snapshots for mutable versioning, in-kernel garbage collection for better efficiency, and quota support to enhance compliance. In November , a second maintainer was added to the project, fostering renewed development interest.

Development and Licensing

Contributors and Maintenance

The development of NILFS was primarily led by engineers from NTT Cyber Space Laboratories in , with Ryusuke Konishi serving as the lead architect and primary maintainer since the project's inception in 2005. Konishi, alongside , spearheaded the core design and initial integration, as detailed in the seminal 2006 paper on its implementation. Other key early contributors from NTT included Yoshiji Amagai, Hisashi Hifumi, Seiji Kihara, Naruhiko Kamimura, and Satoshi Moriai, who focused on log-structured mechanisms and snapshotting features. Global contributions expanded the project's scope through community patches submitted via the linux-nilfs mailing list. Early international involvement came from developers such as Andreas Rohner, who contributed to inode management and error handling improvements, and Jiro Sekiba, who addressed compatibility issues in user-space tools. More recently, Viacheslav Dubeyko (also known as Vyacheslav Dubeyko) was appointed as co-maintainer in November 2025, taking on responsibilities for upstreaming patches to the , similar to maintenance models for other filesystems like HFS+. This addition aims to distribute workload and ensure ongoing stability. NILFS maintenance was initially driven by NTT until a period of reduced activity in the mid-2010s, during which fewer updates reached the mainline kernel. Revival efforts gained momentum in 2024 with targeted fixes for kernel versions 6.10 and 6.11, addressing issues like checkpoint handling and ioctl support. By 2025, activity intensified, including Dubeyko's co-maintainer role for 6.13 and beyond, focusing on bug resolutions and minor enhancements to sustain compatibility with modern hardware. The NILFS community revolves around its project page, which hosts the official repository, documentation, and issue trackers for user-space utilities like mkfs.nilfs2. Development discussions occur on the linux-nilfs@vger. mailing list, where patches and feature requests are reviewed by maintainers and contributors. Recent coverage, such as Phoronix reports on the 2025 maintainer addition, has highlighted this renewed interest, drawing attention to NILFS's potential for log-structured storage in enterprise and embedded environments.

Licensing Details

NILFS's kernel module is licensed under the GNU General Public License version 2 (GPLv2), ensuring compatibility with the kernel's licensing requirements and allowing seamless integration into the kernel distribution. The user-space utilities, collectively known as nilfs-utils, are also released under the GPLv2, which mandates that any modifications or derivative works must be distributed under the same license, promoting . In contrast, the libraries and headers in libnilfs are governed by the GNU Lesser General Public License version 2.1 (LGPLv2.1), a weaker license that permits linking with without requiring the disclosure of the linking application's . These licensing choices provide full availability for all components, fostering community contributions while avoiding compatibility issues seen in filesystems like under the CDDL, thereby enabling broad adoption within environments. NILFS components are freely distributed through official channels such as for the kernel module and for nilfs-utils and libnilfs, with no associated royalties, fees, or usage restrictions beyond the terms of their respective licenses.

References

  1. https://docs.kernel.org/filesystems/nilfs2.html
  2. https://nilfs.sourceforge.io/en/about_nilfs.html
  3. https://nilfs.sourceforge.io/
  4. https://www.phoronix.com/news/NILFS2-Second-Maintainer
  5. https://group.ntt/en/newsrelease/pdf/news/news09e/0906/090611a.pdf
  6. https://group.ntt/en/newsrelease/pdf/news/news05e/0509/050926.pdf
  7. https://nilfs.sourceforge.io/en/faq.html
  8. https://nilfs.sourceforge.io/en/archive.html
  9. https://www.phoronix.com/news/NILFS2-Patches-Coming-6.12
  10. https://lkml.org/lkml/2025/11/8/2
  11. https://www.kernel.org/doc/html/v6.2/filesystems/nilfs2.html
  12. https://nilfs.sourceforge.io/man5/nilfs_cleanerd.conf.5.html
  13. https://nilfs.sourceforge.io/en/man8/nilfs-clean.8.html
  14. https://www.systutorials.com/docs/linux/man/8-nilfs_cleanerd/
  15. https://nilfs.sourceforge.io/en/man5/nilfs_cleanerd.conf.5.html
  16. https://www.kernelconfig.io/config_nilfs2_fs
  17. https://nilfs.sourceforge.io/en/man8/mkfs.nilfs2.8.html
  18. https://nilfs.sourceforge.io/en/manual.html
  19. https://wiki.archlinux.org/title/NILFS2
  20. https://github.com/nilfs-dev/nilfs-utils
  21. https://archlinux.org/packages/core/x86_64/nilfs-utils/
  22. https://www.phoronix.com/review/ext4_btrfs_nilfs2/7
  23. https://www.phoronix.com/review/ext4_btrfs_nilfs2
  24. http://nyx.skku.ac.kr/publications/papers/NAND_Flash_Storage_Device_Performance_in_Linux_File_System.pdf
  25. https://www.phoronix.com/review/linux-58-filesystems
  26. https://man.archlinux.org/man/nilfs_cleanerd.conf.5.en
  27. https://man.archlinux.org/man/nilfs_cleanerd.8.en
  28. http://events17.linuxfoundation.org/sites/events/files/slides/fs-for-embedded-full_0.pdf
  29. https://www.daemon-systems.org/man/mount_nilfs.8.html
  30. https://nilfs.sourceforge.io/en/download.html
  31. https://nilfs.sourceforge.io/en/current_status.html
  32. https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
  33. https://www.kernel.org/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.