Warning: it is the middle of the night and I'm going to ramble. | From: Dhaval Giani via talk <talk@gtalug.org> | People love talking smack about btrfs. Here's some real insight from Josef | Bacik though at | https://lwn.net/ml/fedora-devel/03fbbb9a-7e74-fc49-c663-32722d6f75a2@toxicpa... | and | https://lwn.net/ml/fedora-devel/cf5b4944-74c4-b4a4-0d65-71d9821a4a71@toxicpa.... | Read through the chain. For those who don't know him, Josef is a core btrfs | developer. I also quite like Josef personally, he is a good developer, | great to work with and is personally invested in helping folks out. | | This is a solid fs, Interesting. I've only read a bit so far. Generally, I don't wish to be a guinea pig when it comes to file systems. So I switch very rarely. The EXT series has been good to me. I never switched to Reiser or XFS, mostly due to my conservatism. If I remember correctly, inode numbers in Reiser and perhaps XFS didn't have the properties I expected (i.e. within a file system, there was a stable isomorphism between the numbers and the files). I was going to consider BTRFS when RHEL dropped it. I took that as a Bad Sign. Do you know why they did this? BTRFS progress has seemed painfully slow. To me, that's a sign that it might be too complex. Complexity is my enemy. - too many places for bugs - too much code that isn't tested much - harder to adjust to changing environments Why does compression help with write amplification on SSDs? My understanding is that SSD firmware compresses already. Possible answer: compression of encrypted stuff is ineffective. But BTRFS doesn't encrypt (LUKS can do so underneath BTRFS, it seems). The following are some random thoughts about filesystems. I'm interested in any reactions to these. The UNIX model of a file being a randomly-accessed array of fixed-size blocks doesn't fit very well with compression. Even if a large portion of files are accessed purely as a byte stream. That's perhaps a flaw in UNIX but it is tough to change. In modern systems, with all kinds of crazy containerization, I guess de-duplication might be very useful. As well as COW, I think. Is this something for the File System, or a layer below, like LVM? There's something appealing about modularizing the FS code by composable layers. But not if the overhead is observable. Or the composability leaves rough edges. Here's a natural order for layers: FS (UNIX semantics + ACLS etc, more than just POSIX) de-duplication compression encryption aggregation for efficient use of device? I don't know where to fit in checksums. Perhaps it's a natural part of encryption (encryption without integrity checking has interesting weaknesses). I don't know how to deal with the variable-sized blocks that come out of compression. Hardware has co-evolved with file-systems to expect blocks of 512 or 4096 bytes. (I remember IBM/360 disk drives which supported a range of block sizes as if each track was a short piece of magnetic tape.) I don't know how to have file systems more respectfully reflect the underlying nature of SSDs and shingled HDDs I also am still waiting for translucent mounts like Plan 9. I think that many or most drives do whole-volume encryption invisible to the OS. This really isn't useful to the OS since the whole volume has a single key. The most secure encryption is end-to-end. It tends to be less convenient. Maybe my placement of encryption near the bottom of the stack isn't good enough. I have more questions than answers (or even opinions) and my systems are modest, so I stay with EXT4 directly on old fashioned (GUID) partitions. | there are times when I see the reactions from users and | I really wonder why I do open source work anyway. I'd like to understand this comment better. I work on open source and don't remember feeling anything like that from comments in this thread. Other kinds of comments, perhaps. | I have lost data on all | sorts of filesystems, and I have also been at the end of stupid mistakes | made. Almost everything is recoverable if you stop, and ask for help and | keep your ego out of it. More concretely, stop, make an image copy on the disk, and experiment with that. Ones first actions in a disaster may well compound it. But I find filesystems and editors that lose your data are unforgivable. Sometimes it's just a filesystem that is fragile in the face of hardware errors.