Hacker News Reader

Comment by newcup | Hacker News Reader

I think NILFS is a hidden gem. I’ve been using it exclusively in my Linux laptops, desktops etc. since ca. 2014. Apart from one kernel regression bug related to NILFS2 it’s worked flawlessly (no data corruption even with the bug just no access to the file system; effectively it forced running older kernel while the bug was fixed).

The continuous snapshotting has saved me a couple of times; I’ve just mounted a version of the file system from few hours or weeks ago to access overwritten or deleted data. I use NILFS also on backup disks to provide combined deduplication and snapshots easily (just rsync & NILFS’ mkss, latter to make sure the “checkpoints” aren’t unnoticedly garbage collected in case the backup disk gets full).

View on HN

>I think NILFS is a hidden gem. I’ve been using it exclusively in my Linux laptops, desktops etc. since ca. 2014

Yes it's really sad, there we have a native and stable check-summing fs, and nearly no one knows about it.

> check-summing fs

Is it? Last I'd heard was

> nilfs2 store checksums for all data. However, at least the current implementation does not verify it when reading.

https://www.spinics.net/lists/linux-nilfs/msg01063.html

Hmm you could be right, i found nothing about that it is calculated at read-time. Just with fsck.

BTRFS is also a native copy on write filesystem that verifies a configurable checksum and supports snapshots.

The snapshots are not automatic, but short of that it is pretty feature complete

That's why i specifically wrote -> stable...

BTRFS is not stable?

If it’s not perhaps it should be, I’ve been using it for about 10 years without any problems that I didn’t cause for myself.

BTRFS is pretty stable nowadays.

What does that mean quantifiably?

Synology deploys it in their products

I think it's the default for suse these days.

It is, and openSUSE's default of "create a snapshot before and after every 'zypper in' and/or 'zypper dup'" has saved my bacon on more than one occasion.

SLES explicitly say's just use it for the system NOT Data...there you use XFS.

I’ve used it for about 10 years without consequence; except for problems I had once with enabling experimental options in the kernel module (custom build.) I have used BTRFS exclusively and extensively in terms of what you can do with it since realizing it that many years ago. The only thing I haven’t used is its native RAID support. I think 0 and 1 are fine but I’m not sure about 5/6; parity was still experimental last I checked in 2016 maybe it’s reliable now. Everything else though; compression, snapshots, copy on write, online defrag has all been fine. It is the default for SuSE Leap and Tumbleweed, they use it for snapper (OS snapshots) and BTRFS sub volumes are also supported by Docker for container images and containers. It saves a lot of space when images start to add up.

The name isn’t great, as someone unfamiliar with it, it sounds like a synonym of ‘Null FS’ and elicits thoughts of a mock filesystem for testing. In a list of filesystems I would gloss straight over it

> Apart from one kernel regression bug related to NILFS2 it’s worked flawlessly

Maybe on x86? I’ve tried repeatedly to use it on ARM for RaspberryPi where it would have been perfect, but always ran into various kernel panics as soon as the file system is mounted or accessed.

True, I only have used it on x86 devices. Thanks for the heads up!

I’ve heard so many stories of SD card failures (against which snapshotting might be of no help) with RaspberryPi that I’ve decided to send any valuable data promptly to safety over a network. (Though, I personally haven’t had any problems with failing SD’s.)

I've used NILFS2 on flash storage on some old non-RPi ARMv7 hardware for a while without a problem. Switched to F2FS for performance reasons, though.

This was on the root partition, which is subjected to a lot more concurrency issues than an sd card normally would fwiw.

NILFS is absolutely wonderful; it was very unfortunate that Linus chose to dub btrfs as the ext4 successor all those years ago, because it cut off a lot of interest in the plethora of interesting work that was going on at the time.

A decade later and btrfs is still riddled with problems and incomplete, people are still using xfs and ext4 for lack of trust, one kernel dev has a side hobby trying to block openzfs, and excellent little projects like nilfs are largely unknown.

> one kernel dev has a side hobby trying to block openzfs

Can you elaborate?

I don't know if everything has been collected in an easy-to-digest form, but GKH has gone out of his way a few times to shut out OpenZFS.

Exactly. Removing or changing the licensing on APIs in a way carefully targeted to break ZFS, but not affect actual proprietary drivers such as the NVidia graphics drivers.

> it was very unfortunate that Linus chose to dub btrfs as the ext4 successor

That quote is from Ted T'so (https://en.wikipedia.org/wiki/Btrfs#History) or do you have a link to Linus' quote?

Reply on news.ycombinator.com