@p @RedTechEngineer @nyanide @raphiel_shiraha_ainsworth @bonifartius

>I think sjw was running it for something at some point.

He was also running NB on Arch for some time, if I remember correctly, so it doesn't really surprise me :D

>so maybe it doesn't blow up as much any more or maybe it is still the expected btrfs experience.

It still can blow up when it looses free space and since they broke the free space reporting _intentionally_, a lot of userspace utilities that calculate free space before committing transactions will blow up with it. Unless they use custom code linked from libbtrfs that is. Probably one of the most braindead decisions one could make in filesystem design.

>Even ext4 blew up on me the first time I tried it, at which point I decided to not even bother looking at filesystems unless they've been in production for several years.

I had ext4 survive a bad USB cable that created garbage data and deadlocked the HDD's controller multiple times. It only took 40GB of swap and a day of fsck.ext4 constantly complaining about something to fix it. In the end no data was lost.

>ZFS does the same with RAID and LVM and the entire I/O subsystem. They should probably rename it NIHFS.

It acts like malware in the entire disks and I/O subsystem, sticking its fingers everywhere it can, but usually for a good reason. When it falls apart is applications trying to be too smart with I/O (1). One can only appreciate the whole DB-like design and extreme paranoia with everything I/O related, when they use it on a large disk array. Other than that, it's a bad filesystem to use on your daily-driver system. None of the benefits with all of the issues. Running it under Linux is also probably a bad idea, just use vanilla FreeBSD or TrueNAS.

(1) You can disable a lot of the "smart" features per every pool, so this problem usually only crops up in misconfigured environments.