3 ms·

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

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.

mike_hock 3y ago
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.
- kevincox 3y ago
  > 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).
  - Hello71 3y ago
    > 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.
    - mike_hock 3y ago
      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.
      - Tobu 3y ago
        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).
jhoechtl 3y ago
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
- the_duke 3y ago
  btrfs does not have the fast-disk cache feature I think, and definitely not the built-in encryption.
  - deleted 3y ago
    [deleted]
  - MrDrMcCoy 3y ago
    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!

mike_hock 3y ago

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.

kevincox 3y ago
> 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).
- Hello71 3y ago
  > 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.
  - mike_hock 3y ago
    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.
    - Tobu 3y ago
      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).

jhoechtl 3y ago

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

the_duke 3y ago
btrfs does not have the fast-disk cache feature I think, and definitely not the built-in encryption.
- deleted 3y ago
  [deleted]
- MrDrMcCoy 3y ago
  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!