5 ms·

While I really like these sort of file systems, I'm not holding my breath. This isn't a simple filesystem project, but plays in the next-gen space ZFS opened u

by ysleepy 10y ago

While I really like these sort of file systems, I'm not holding my breath. This isn't a simple filesystem project, but plays in the next-gen space ZFS opened up. There will be a lot to do, especially IO scheduling, RAID safety with shitty drive firmwares, consistency guarantees with fsync/partial flushes etc. I'm pessimistic about it being mainlined in the near future, the core team will be weary of a second btrfs. What I would like to see is a APFS/exFAT crossover with COW and data checksums without all the volume mgmt with ports for all possible operating systems so everyone can use it for their SDcards, usb-sticks and external drives without making tradeoffs and using fuse.

gbrown_ 10y ago
> with COW and data checksums without all the volume mgmt The fact that the raidz volume is not an opaque block device allows ZFS to be aware of data corruption when comparing checksums and self heal if the data can be re-constructed from the array. I'm not saying any attempt at a new filesystem should have to bundle the two layers together, but they should allow for communication between the abstractions.
sedachv 10y ago
> What I would like to see is a APFS/exFAT crossover with COW and data checksums without all the volume mgmt with ports for all possible operating systems so everyone can use it for their SDcards, usb-sticks and external drives without making tradeoffs and using fuse. +1. Filesystems without bit-rot protection on flash drives are going to become at least as big a problem as optical disc rot.
- mschuster91 10y ago
  > without making tradeoffs and using fuse. What's the problem with fuse? It allows sharing code between Linux, OS X, (Free)BSD and even Windows (via dokan). Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there.
  - sedachv 10y ago
    > What's the problem with fuse? 1. Only available on Android when rooted. 2. Support varies between OSes. For example OpenBSD's FUSE does not have the default_permissions/allow_other flags, which makes for example encfs (and any other virtual filesystems that are backed by multiple files) a pain to use since OpenBSD 6.0 removed user mounting.
    - khc 10y ago
      1. most filesystems won't be available on Android anyway, this point is moot 2. most non-fuse filesystems won't be ported to your BSD of choice anyway
  - Veratyr 10y ago
    > Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there. This might be the case if you're running something incredibly easy on I/O like large sequential read/writes, but if you do anything at all challenging on I/O like opening desktop applications (Photoshop, lots of random reads), editing or viewing high bitrate video (very high throughput) or god forbid running a database, this is a huge problem.
legulere 10y ago
Well we can still hope that Apple might open source APFS (and add data checksums). Or that someone sits down and does the reverse engineering work.
__david__ 10y ago
I'm more optimistic. What you may or may not know is that bcachefs is a tweak on bcache, which has already been mainlined and is pretty stable (I've personally been running bcache for a couple years on my home linux machine). The point is a lot of the things you bring up are already covered by bcache. Bcachefs "just" adds a filesystem layer on the bcache tree structure.

by ysleepy 10y ago

gbrown_ 10y ago

> with COW and data checksums without all the volume mgmt The fact that the raidz volume is not an opaque block device allows ZFS to be aware of data corruption when comparing checksums and self heal if the data can be re-constructed from the array. I'm not saying any attempt at a new filesystem should have to bundle the two layers together, but they should allow for communication between the abstractions.

sedachv 10y ago

> What I would like to see is a APFS/exFAT crossover with COW and data checksums without all the volume mgmt with ports for all possible operating systems so everyone can use it for their SDcards, usb-sticks and external drives without making tradeoffs and using fuse. +1. Filesystems without bit-rot protection on flash drives are going to become at least as big a problem as optical disc rot.

mschuster91 10y ago
> without making tradeoffs and using fuse. What's the problem with fuse? It allows sharing code between Linux, OS X, (Free)BSD and even Windows (via dokan). Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there.
- sedachv 10y ago
  > What's the problem with fuse? 1. Only available on Android when rooted. 2. Support varies between OSes. For example OpenBSD's FUSE does not have the default_permissions/allow_other flags, which makes for example encfs (and any other virtual filesystems that are backed by multiple files) a pain to use since OpenBSD 6.0 removed user mounting.
  - khc 10y ago
    1. most filesystems won't be available on Android anyway, this point is moot 2. most non-fuse filesystems won't be ported to your BSD of choice anyway
- Veratyr 10y ago
  > Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there. This might be the case if you're running something incredibly easy on I/O like large sequential read/writes, but if you do anything at all challenging on I/O like opening desktop applications (Photoshop, lots of random reads), editing or viewing high bitrate video (very high throughput) or god forbid running a database, this is a huge problem.

legulere 10y ago

Well we can still hope that Apple might open source APFS (and add data checksums). Or that someone sits down and does the reverse engineering work.

__david__ 10y ago

I'm more optimistic. What you may or may not know is that bcachefs is a tweak on bcache, which has already been mainlined and is pretty stable (I've personally been running bcache for a couple years on my home linux machine). The point is a lot of the things you bring up are already covered by bcache. Bcachefs "just" adds a filesystem layer on the bcache tree structure.