Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux NILFS file system: automatic continuous snapshots

dataswamp.org

Post reply on HN
Print view View original

101–110 of 158 posts

Re: Linux NILFS file system: automatic continuous snapshots

#101

Post by ggm »

usr1106 wrote: post #86
ggm wrote: post #84

Didn't VMS have this baked in? My memory is that all 8.3 file names had 8.3[;nnn] version tagging under the hood

That's what it looked like, but I doubt it was deep in the filesystem. It was basically just a naming convention. User had to purge old versions manually. This gets tedious if you have many files that change often. Snapshots are a safety net, not something you want to have in your way all day long.

Er.. my memory is that it did COW inside VMS fs semantics and was not manually achived. You did have to manually delete. So I don't think it was just a hack.

It didn't do directories so was certainly not as good as snapshot but we're talking 40 years ago!

Re: Linux NILFS file system: automatic continuous snapshots

#102

Post by tjoff »

lazide wrote: post #57
mustache_kimono wrote: post #55

Earlier quoted context omitted.

And that may work for btrfs, but again at some cost: "When you enable nocow on your files, Btrfs cannot compute checksums, meaning the integrity against bitrot and other corruptions cannot be guaranteed (i.e. in nocow mode, Btrfs drops to similar data consistency guarantees as other popular filesystems, like ext4, XFS, ...). In RAID modes, Btrfs cannot determine which mirror has the good copy if there is corruption o…

Yup. It’s a pretty fundamental thing. COW and data checksums (and usually automatic/inline compression) co-exist that way because it’s otherwise too expensive performance wise, and potentially dangerous corruption wise. For instance, if you modify a single byte in a large file, you need to update the data on disk as well as the checksum in the block header, and other related data. Chances are, these are in different…

> Chances are, these are in different sectors, and also require re-reading in all the other data in the block to compute the checksum. Anywhere in that process is a chance for corruption of the original data and the update.

Not much different than any interrupted write though. And a COW needs to reread just as much.

> If the byte changes the final compressed size, it may not fit in the current block at all, causing an expensive (or impossible) re-allocation.

Something that you must always pay in a COW filesystem anyway? Is handled by other non-COW filesystems anyway.

Just because a filesystem isn't COW doesn't mean every change needs to be in place either. Of course, a filesystem that is primarily COW might not want to maintain compression for non-COW edge-cases and that is quite reasonable.

Re: Linux NILFS file system: automatic continuous snapshots

#103

Post by wazoox »

mdaniel wrote: post #52
wazoox wrote: post #31

I've been running NILFS2 on my main work NAS for 8 years. It never failed us :)

I mean this honestly: how did you evaluate such a new filesystem in order to bet a work NAS upon it?

I've made some testing, and installed it on a secondary system that in the beginning mostly hosted unimportant files. Then we added more things, and as after a few years it posed absolutely no problem we went further (and added a backup procedure). Then we migrated to new hardware, and it's still going strong (it's quite small, about 15 TB volume).

Re: Linux NILFS file system: automatic continuous snapshots

#104

Post by rodgerd »

newcup wrote: post #12

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…

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.

Re: Linux NILFS file system: automatic continuous snapshots

#105

Post by rodgerd »

didgetmaster wrote: post #39

Does NILFS do checksums and snapshotting for every single file in the system? One of my biggest complaints about file systems in general is that they are all designed to treat every file the exact same way. We now have storage systems (even SSDs) that are big enough to hold hundreds of millions of files. Those files can be a mix of small files, big files, temp files, personal files, and public files. Yet every file s…

> Does NILFS do checksums and snapshotting for every single file in the system?

NILFS is, by default, a filesystem that only ever appends until you garbage collect the tail. It doesn't really "snapshot" in the way that ZFS or btrfs do, because you can just walk the entire history of the filesystem until you run out of history. The snapshots are just bookmarks of a consistent state.

Re: Linux NILFS file system: automatic continuous snapshots

#106

Post by mustache_kimono »

Arnavion wrote: post #100
mustache_kimono wrote: post #93

Earlier quoted context omitted.

> the safest RAID experience seems to be filesystem on mdadm on dm-integrity on disk partition, so that the RAID and RAID errors are invisible to the filesystem. I suppose I don't understand this. Why would this be the case?

dm-integrity solves the problem of identifying which replica is good and which is bad. mdadm solves the problem of reading from the replica identified as good and fixing / reporting the replica identified as bad. The filesystem doesn't notice or care.

Ahh, so you intend, "If you can't use ZFS/btrfs, use dm-integrity"?

Re: Linux NILFS file system: automatic continuous snapshots

#107

Post by heavyset_go »

ComputerGuru wrote: post #67
newcup wrote: post #12

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…

> 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.

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.

Re: Linux NILFS file system: automatic continuous snapshots

#108

Post by [deleted] »

mustache_kimono wrote: post #41
harvie wrote: post #23

Earlier quoted context omitted.

Perhaps we can leverage "inotify" API to make ZFS snapshot everytime some file had been changed... But i think ZFS is not really good at handling huge amounts of snapshots. The NILFS2 snapshots are probably more lightweight when compared to ZFS ones.

> Perhaps we can leverage "inotify" API to make ZFS snapshot everytime some file had been changed... ZFS and btrfs users are already living in the future: inotifywait -r -m --format %w%f -e close_write "/srv/downloads/" | while read -r line; do # command below will snapshot the dataset # upon which the closed file is located sudo httm --snap "$line" done See: https://kimono-koans.github.io/inotifywait/

[deleted]

Re: Linux NILFS file system: automatic continuous snapshots

#109

Post by Arnavion »

mustache_kimono wrote: post #106
Arnavion wrote: post #100

Earlier quoted context omitted.

dm-integrity solves the problem of identifying which replica is good and which is bad. mdadm solves the problem of reading from the replica identified as good and fixing / reporting the replica identified as bad. The filesystem doesn't notice or care.

Ahh, so you intend, "If you can't use ZFS/btrfs, use dm-integrity"?

No. I don't use ZFS since it's not licensed correctly, so I have no opinion on it. And BTRFS raid is not safe enough for use. So I'm saying "Use filesystem on mdadm on dm-integrity".

Re: Linux NILFS file system: automatic continuous snapshots

#110

Post by ephbit »

compsciphd wrote: post #61
sargun wrote: post #48

I've always wondered why NILFS (or similar) isn't used for cases where ransomware is a risk. I'm honestly surprised that it's not mandated to use a append-only / log-structured filesystem for some critical systems (think patient records), where the cost of losing data is so high, rarely mutated, and trading it off for wasting storage isn't that bad (after all, HDD storage is incredibly cheap, and nobody said you had…

you don't need a log structured fs to do this, you could just have regular zfs/btrfs snapshots too. BUT if an attack has the ability to delete an entire file system / encrypt it, they really have the ability to delete the snapshots as well, the only reason they might not is due to "security through obscurity". now, what I have argued is that an append only file system which works in a SAN like environment (i.e. you h…

> if an attack has the ability to delete an entire file system / encrypt it, they really have the ability to delete the snapshots as well, ..

How so?

Let's say you have one machine holding the actual data for working on it. And some backup server. You could use btrfs send over ssh and regularly btrfs receive the data on the backup machine. Even it they got encrypted by ransomware they wouldn't be lost in the backups. As long as they're not deleted there how could a compromised work machine compromise the data on the backup machine?

Post reply on HN