Hacker News Reader

Comment by Volundr | Hacker News Reader

NILFS is really, really cool. In concept. Unfortunately the tooling and support just isn't there. I ran it for quite some time on my laptop and the continuous snapshoting is everything I hoped it'd be. At one point however there was a change to the kernel that rendered it unbootable. Despite being a known and recorded bug it took forever to get fixed (about a year if I recall correctly) leaving me stuck on an old kernel the whole time.

This was made more frustrating by the lack of any tooling such as fsck to help me diagnose the issue. The only reason I figured out it was a bug was that I booted a live CD to try to rescue the system and it booted fine.

When I finally replaced that laptop I went back to ZFS and scripted snapshots. As much as I want to, I just can't recommend NILFS for daily use.

View on HN

Do you happen to remember which change in kernel was the cause?

I had troubles with un-popular file systems as root file system when the initrd was not built properly. So sysresccd is always good to have in reach.. Saying this, I think I won't have any other file system on root besides the default of the distro. Data which require special care are on other partitions.

How did Linus not go on a rampage after breaking userspace for an entire year? Is NILFS not part of the kernel mainline, I guess?

> How did Linus not go on a rampage after breaking userspace for an entire year?

Linus' commandment about not breaking userspace is frequently misunderstood. He wants to ensure that user-space /programs/ do not break (even if they rely on buggy behavior that made it into a release), not that the /user/ will never see any breakage of the system whatsoever, which is of course an impossible goal. Device drivers and filesystems are firmly system-level stuff, bugs and backwards-incompatible changes in those areas are regrettable but happen all the same.

If I understand correctly, I don't think this is a userspace-breaking bug, as in: a kernel API changed and made a userspace program not work anymore.

It is a bug that prevents the kernel from booting. That's bad, but that's not the same thing. That's not a userspace compatibility issue such as the ones Linus chases. The user space isn't even involved if the kernel cannot boot. Or if it is actually a userspace program that causes a kernel crash, it is a crash, which is not really the same thing as an API change (one could argue, but that's a bit far-fetched, the intents are not the same, etc - I don't see Linus explode on somebody who introduced a crash the way he would explode on someone changing a userspace API).

> Is NILFS not part of the kernel mainline, I guess?

Good guess, but no:

https://github.com/torvalds/linux/tree/master/fs/nilfs2

> How did Linus not go on a rampage after breaking userspace for an entire year?

I would very much like to know that as well. Any chance it didn't get reported (at least, not as "this broke booting")?

I reported it along with a few other users in https://marc.info/?l=linux-nilfs&m=157540765215806&w=2. I think it just isn't widely enough used that Linus noticed we were broken. If I recall correctly it also wasn't directly fixed so much as incidentally. I just kept checking new kernel versions as they were released until one worked. There was never anything in the change-log (that I recall) about fixing the bug, just another change that happened to fix the issue.

Edit: Looking through the archives, it looks like my memory was somewhat uncharitable. It was reported in November and directly patched in June (https://marc.info/?l=linux-nilfs&m=159154670627428&w=2) so about 7 months after reporting. Not sure what kernel release that would've landed in, so could've been closer to 8.

Reply on news.ycombinator.com