Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Finally, we get a non-journaled semi-cross-platform filesystem. fat32 just wasn't cutting it... /s

When will we get a proper performant journaled cross platform filesystem that doesn't require additional software on Windows, MacOS, and Linux? I can't believe we still don't have anything like that.



Btrfs and WinBtrfs. The file system is the journal. https://github.com/maharmstone/btrfs

Previous discussion on WinBtrfs https://news.ycombinator.com/item?id=15177002

Journal is about obviating fsck, just do journal replay to make the fs consistent again. I think for most media like USB sticks, the most platform interoperable file system is UDF. The gotcha that trips most people up I think, is that you shouldn't partition the media device. Just format the whole block device as UDF. I do this with mkuddf using defaults and it works fine across all three operating systems with similar performance as FAT32.


I think the complexity of btrfs and its mix of device and file system layers rules it out for general purposes.


The file format is very simple. The write guarantees of the file system for full OS usage may not be simple, certainly they're not simple on Linux, and Btrfs development shows that this is hard.

The GRUB Btrfs driver is pretty small considering the Btrfs feature set. And yet it understands all the multiple device stuff, the logical and physical device abstraction, and snapshots and subvolume navigation.

I like always on checksums for every block, both metadata and data. It's a good fit for the cheaper flash media out there including USB sticks which non-deterministically report back garbage, rather than a discrete read error.


Why?

I use it on my laptop with 0 issues. It’s really not that complicated...


It's not about that - the filesystem needs to be simple snough that multiple vendors' implementations will be compatible.

Remember SOAP interoperability? Me neither. It was too complex for its own good. That's why REST is used everywhere today and experienced web developers smile every now and then when they remember they don't need to use it anymore. Well, most of them at least...


I’m not talking about complexity to use but rather architectural complexity. Rather than being a simple fs driver, it (in the ZFS model) consumes raw devices then re-exposes them as software-defined volumes optionally with a file system api already exposed or as software defined block devices that can then be formatted with another filesystem.

It basically upends the entire separation of layers and requires a completely different approach to use.


Btrfs actually has a simpler interface than ZFS: it consumes block devices and exposes only a filesystem, not more block devices. It does have integrated volume management functionality, but overall acts much more like a "regular" filesystem than ZFS.


>Finally, we get a non-journaled semi-cross-platform filesystem. fat32 just wasn't cutting it... /s

Hope you never had to store files larger than 4GB otherwise FAT32 would not work for you. (Before you respond with "that's what archive files / files splitting are for", not every device that takes files on an SD card and supports FAT32 has a way to join files on the fly/a way to read archived files.)


With WSL, shouldn't it be possible to use any native Linux file system?


Only sort of. Windows communicates with WSL via 9p, which has decent performance but is still a network protocol. It certainly isn't possible to mount an ext4 filesystem on D: with native performance.


Does this mean I can use libvirt to expose a directory on my system via 9p and use it within Windows?


Maaaybe. Hadn't considered the option, honestly.


Does UDF count?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: