NILFS2 support
Closed this issue · 4 comments
NILFS2 is a mature log-structured file system, which supports snapshots. It's exclusively designed for flash devices only.
It's better suitable for low-end devices (e.g. phones, Raspberry Pi and other minicomputers) than ZFS and BTRFS. It requires less CPU and RAM than ZFS, and provides better read-write performance than BTRFS.
Similarly to BTRFS and ZFS, it saves the entire filesystem in a snapshot, so this tool would be a good fit.
Thanks for filing this feature request.
NILFS2 is a mature log-structured file system, which supports snapshots. It's exclusively designed for flash devices only.
Well aware of NILFS2! It served as inspiration for ounce.
Similarly to BTRFS and ZFS, it saves the entire filesystem in a snapshot, so this tool would be a good fit.
Yeah, it might be. httm started a ZFS only tool, because I use ZFS, and ZFS transparently makes available ZFS snapshots with its .zfs directory.
BTRFS does nothing similar. BTRFS snapshots are available where ever you want them. Why? I couldn't tell you. The snapshot tool Snapper has a well defined directory structure for snapshots, and via parsing the btrfs subvolume list -a -s $mount_path command, I am able to determine the snapshot locations for non-Snapper systems.
So -- a few things. Developing BTRFS support was a pain. No one told me how to do any of it. The BTRFS enthusiasts told me it was impossible, and I had to figure out how it works on its own.
Even now that it is working I get very little feedback about how its working, and I don't regularly test the BTRFS support, because, like I said, I'm a ZFS guy (like Ford or Chevy guy). And a NILFS2 fan, like you, would need to be enthusiastic about this support, and regularly use it to make sure it's working. If its not going to be used, I'm not going to bother with it.
So -- I'd be pleased to add NILFS2 support, but only if you, or someone else who loves NILFS2, figures out the snapshot detection problem, and basically any other NILFS2 filesystem specific issues. However, after a quick look, NILFS2 does seem promising:
# mount -t nilfs2
/dev/sdb1 on /nilfs type nilfs2 (rw,gcpid=13296)
/dev/sdb1 on /nilfs-cp type nilfs2 (ro,cp=2)
It seems as though I would only need to find all mounts with the same source, here /dev/sdb1 and any which had a cp=X key value would be my snapshot mounts for the source? If that's all that needs to be done, this is initial support is easy. knock on wood
And I suppose snapshot auto-mounting would be up to the user? Or is there some better way? The question is -- how useful is this initial support if you have to mount each snapshot manually, as you make them?
Any other issues lurking that I might be missing?
As far as I know, NILFS snapshots are only exposed via the mount option.
Auto-mounting can be done with scripts, based on the output of lscp.
I would be happy to regularly test this functionality.
This branch seems to be working: https://github.com/kimono-koans/httm/tree/nilfs2_support
➜ /mnt sudo httm fakefile
─────────────────────────────────────────────────────────────────
Sat Feb 18 11:27:35 2023 0 bytes "/mnt/.snapshots/3/fakefile"
Sat Feb 18 11:38:24 2023 0 bytes "/mnt/.snapshots/10/fakefile"
Sat Feb 18 11:38:41 2023 6 bytes "/mnt/.snapshots/14/fakefile"
Sat Feb 18 11:39:25 2023 15 bytes "/mnt/.snapshots/18/fakefile"
─────────────────────────────────────────────────────────────────
Sat Feb 18 11:39:25 2023 15 bytes "/mnt/fakefile"
─────────────────────────────────────────────────────────────────You can build from source using the instructions in the README.
Let me know your thoughts. Again the actual mounting of any snapshots will need to be done by the user.