Hacker News Reader

Comment by the_duke | Hacker News Reader

Exciting!

I've played around with it a few times, since it's been easily available in NixOS for a while. Didn't run into any issues with a few disks and a few hundred GB of data.

Some very interesting properties, including (actually efficient) snapshots, spreading data over multiple disks, using a fast SSD as a cache layer for HDDs, built-in encryption (not audited yet though!), automatic deduplication, compression, ...

A lot of that is already available through other file systems (btfs, zfs) and/or by layering different solutions (LVM, dm-crypt, ...) , but getting all of it out of the box with a single FS that's in the mainline kernel is quite appealing.

View on HN

I don't find this lack of separation of concerns appealing, especially for crypto since it dilutes auditing resources. And blockdev-level crypto is simpler and harder to fuck up.

Snapshots and compression OTOH are better done on the FS level.

> blockdev-level crypto is simpler and harder to fuck up.

Simpler yes, but since generally no extra metadata is allocated it is vulnerable to some cryptanalysis notably comparing different snapshots of the drive. Doing this properly requires storing unique keys for different versions of data. Doing this with typical blockdev-level encryption is very expensive (you either need to reduce the effective block size which disrupts lots of software that assumes things about block size or store the data out-of-line (typically at the end of the disk) which requires up to 2x writes. Doing this in the filesystem allows strong encryption with minimal performance impact (as the IV write is co-located with data that is changing anyways).

> or store the data out-of-line [...] which requires up to 2x writes

and because writes to separate sectors aren't atomic, you probably want to add journaling or some kind of CoW for crash safety, and oh look now you're actually just writing a filesystem and it's not simpler anymore.

No, you're writing something that happens to resemble a small subset of the functionality of a filesystem.

Most importantly, you're not duplicating the effort for every filesystem that you want to support encryption for, and the code can largely remain fixed once mature.

kernel developers are free to factor in common functionality, calling into it library style, without making it into an externally visible layer. IIRC fs encryption and case insensitivity are often done that way, and I think I'd count the page cache and bios as larger library-style components as well (as opposed to the VFS layer which is more in a framework style).

It should be highlighted that all these features are supported by btrfs too which has certainly seen much more test in the last years.

Yes there have been issues in the past but since quite a a while its stable and feature-rich. Easily the most advanced free file system

btrfs does not have the fast-disk cache feature I think, and definitely not the built-in encryption.

It also doesn't do block volumes or active dedupe. Btrfs is great, but I'm very excited about having all these features in one place!

Reply on news.ycombinator.com