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

51–60 of 158 posts

Re: Linux NILFS file system: automatic continuous snapshots

#51

Post by Conan_Kudo »

mustache_kimono wrote: post #45
nix23 wrote: post #42

Earlier quoted context omitted.

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

On Btrfs, you can mark a folder/file/subvolume to have nocow, which has the effect of only doing a COW operation when you are creating snapshots.

Re: Linux NILFS file system: automatic continuous snapshots

#53

Post by yonrg »

koolba wrote: post #4

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

I run this setup. zfs + zfsnap (not cron anymore, now systemd.timer).

I cannot tell if NILFS is doing this too, with zfsnap I maintain different retention times. 5-minutely for 1hour, hourly for 1day, daily for a week. That are less than 60 snapshots. The older ones are cleaned up.

In addition, zfs brings compression and encryption. That's why I have it on the laptops, too.

Re: Linux NILFS file system: automatic continuous snapshots

#54

Post by yonrg »

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 would do it by using it! ... and probably some backup

Re: Linux NILFS file system: automatic continuous snapshots

#55

Post by mustache_kimono »

Conan_Kudo wrote: post #51
mustache_kimono wrote: post #45

Earlier quoted context omitted.

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

On Btrfs, you can mark a folder/file/subvolume to have nocow, which has the effect of only doing a COW operation when you are creating snapshots.

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 on one of them."[0]

[0]: https://wiki.tnonline.net/w/Blog/SQLite_Performance_on_Btrfs...

Re: Linux NILFS file system: automatic continuous snapshots

#56

Post by lazide »

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…

Why is it ‘wasted’? Those things are mostly free on modern hardware.

The challenge with your thesis here is that the only one who can know what is ‘that important’ is YOU, and your decision making and communication bandwidth is already the limiting factor.

For many users, that cat video would be heartbreaking to lose, and they don’t have term papers to worry about.

So having to decide or think what is or is not ‘important enough’ to you, and communicate that to the system, just makes everything slower than putting everything on a system good enough to protect the most sensitive and high value data you have.

Re: Linux NILFS file system: automatic continuous snapshots

#57

Post by lazide »

mustache_kimono wrote: post #55
Conan_Kudo wrote: post #51

Earlier quoted context omitted.

On Btrfs, you can mark a folder/file/subvolume to have nocow, which has the effect of only doing a COW operation when you are creating snapshots.

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

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.

You could end up with the original data and update both invalid.

Writing out a new COW block is done all at once, and if it fails, the write failed atomically, with the original data still intact.

Re: Linux NILFS file system: automatic continuous snapshots

#58

Post by masklinn »

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.

Afaik Time Machine does not do continuous snapshots, just periodic (and triggered).

So you can already do that with zfs: take a snapshot and send it to the backup drive.

Re: Linux NILFS file system: automatic continuous snapshots

#59

Post by compsciphd »

we used NILFS 15 years ago in dejaview - https://www.cs.columbia.edu/~nieh/pubs/sosp2007_dejaview.pdf

We combined nilfs + our process snapshotting tech (we tried to mainline it, but it didn't go, but many of the concepts ended up in CRIU though) + our remote display + screen reading tech (i.e. normal APIs) to create an environment that could record everything you ever saw visually and textually. enable you to search it and enable you to recreate the state as it was at that time with non noticeable interruption to the user (processes downtime was like 0.02s).

Re: Linux NILFS file system: automatic continuous snapshots

#60

Post by spookthesunset »

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…

It might sound weird but the hard part of what you describe is not the technology but how to design the UX in a way that you aren’t babysitting everything.

And doing that is not at all easy. For all anybody knows your cat video is “worth more” to you than your thesis paper. How can you get the system to determine the worth of each file without manually setting an attribute each time you create a file? And if you let the system guess, the cost of failure could be very high! What if it decided your thesis paper was worthless and stored it will a lower “integrity” (or whatever you call the metric)?

I dunno. Storage is getting cheaper all the time and it might just be easier to fuck it and treat all files with the same high level of integrity. Maybe it would be so much work for a user to manually manage they’d just mark everything the same?

Post reply on HN