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

41–50 of 158 posts

Re: Linux NILFS file system: automatic continuous snapshots

#41

Post by mustache_kimono »

harvie wrote: post #23
goodpoint wrote: post #5

Earlier quoted context omitted.

There is no comparison. NILFS provides *continuous* snaphots, so you can inspect and rollback changes as needed. It does without a performance penalty compared to other logging filesystems. And without using additional space forever. The backlog rotates forward continuously. It's a really unique feature that makes a lot of sense for desktop use, where you might want to recover files that were created and deleted afte…

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/

Re: Linux NILFS file system: automatic continuous snapshots

#42

Post by nix23 »

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…

Well you can do that kind of with zfs filesystems, and the "object" is the recordsize.

Re: Linux NILFS file system: automatic continuous snapshots

#43

Post by pkulak »

goodpoint wrote: post #5
koolba wrote: post #4

How does this compare to ZFS + cron to create snapshots every X minutes?

There is no comparison. NILFS provides *continuous* snaphots, so you can inspect and rollback changes as needed. It does without a performance penalty compared to other logging filesystems. And without using additional space forever. The backlog rotates forward continuously. It's a really unique feature that makes a lot of sense for desktop use, where you might want to recover files that were created and deleted afte…

> There is no comparison.

What if I compare it to BTRFS + Snapper? No performance penalty there, plus checksumming.

Re: Linux NILFS file system: automatic continuous snapshots

#44

Post by mustache_kimono »

1MachineElf wrote: post #9
goodpoint wrote: post #5

Earlier quoted context omitted.

There is no comparison. NILFS provides *continuous* snaphots, so you can inspect and rollback changes as needed. It does without a performance penalty compared to other logging filesystems. And without using additional space forever. The backlog rotates forward continuously. It's a really unique feature that makes a lot of sense for desktop use, where you might want to recover files that were created and deleted afte…

>It's a really unique feature that makes a lot of sense for desktop us Sounds like it could serve as a basis for a Linux implementation of something like Apple Time Machine.

With 'httm', a few of us are already living in that bright future: https://github.com/kimono-koans/httm

Re: Linux NILFS file system: automatic continuous snapshots

#45

Post by mustache_kimono »

nix23 wrote: post #42
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…

Well you can do that kind of with zfs filesystems, and the "object" is the recordsize.

I was going to ask: "Is there any limit on the number of ZFS filesystems in a pool?" Google says 2^64 is the limit.

Couldn't one just just generate a filesystem per object if snapshots, etc., on a per object level is what one cared about? Wonder how quickly this would fall over?

> Backup, encryption, COW, checksums, and other operations should not be wasted on a bunch of data that no one really cares about.

This GP comment is a little goofy though. There was a user I once encountered who wanted ZFS, but a la carte. "I want the snapshots but I don't need COW." You have to explain, "You don't get the snapshots unless you have the COW", etc.

Re: Linux NILFS file system: automatic continuous snapshots

#46

Post by AshamedCaptain »

pkulak wrote: post #43
goodpoint wrote: post #5

Earlier quoted context omitted.

There is no comparison. NILFS provides *continuous* snaphots, so you can inspect and rollback changes as needed. It does without a performance penalty compared to other logging filesystems. And without using additional space forever. The backlog rotates forward continuously. It's a really unique feature that makes a lot of sense for desktop use, where you might want to recover files that were created and deleted afte…

> There is no comparison. What if I compare it to BTRFS + Snapper? No performance penalty there, plus checksumming.

btrfs and snapperd do have a performance penalty as the number of snapshots increases. Having 100+ usually means snapper list will take north of an hour. You can easily reach these numbers if you are taking a snapshot every handful of minutes.

Even background snapper cleanups will start to take a toll, since even if they are done with ionice they tend to block simultaneous accesses to the filesystem while they are in progress. If you have your root on the same filesystem, it's not pretty -- lots of periodic system-wide freezes with the HDD LEDs non-stop blinking. I tend to limit snapshots always to < 20 for that reason (and so does the default snapperd config).

Re: Linux NILFS file system: automatic continuous snapshots

#48

Post by sargun »

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 to keep the working set and the log on the same device).

Re: Linux NILFS file system: automatic continuous snapshots

#49

Post by tommiegannert »

rcthompson wrote: post #10
Rygian wrote: post #7

How close is this to a large continuous tape loop for video surveillance? I would very much welcome a filesystem that breaks away from the directories/files paradigm. Any time-based data store would greatly benefit from that.

I think all you would need to add is a daemon that automatically deletes the oldest file(s) whenever free space drops below a certain threshold, so that the filesystem GC can reclaim that space for new files.

If NILFS is continuously checkpointing, couldn't you even remove the file right after you add it, for simplicity?

Re: Linux NILFS file system: automatic continuous snapshots

#50

Post by yonrg »

Volundr wrote: post #11

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 ker…

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.

Post reply on HN