Hacker News Reader

Comment by steeleduncan | Hacker News Reader

Yes, the most concrete issue the article mentions is losing data on Btrfs, but that is well known to be a flaky, semi-experimental file system, the operating system has very little to do with it. The equivalent would be running Debian on ext4

Also, the article mentions Kubernetes a few times, which quite fairly has a reputation for massive complexity, but is again entirely optional, and a piece of software entirely separate from the operating system.

I agree with the basic point of achieving reliability by using the simplest technology available, but the focus on the operating system for me is misguided here, and at best a temporary fix. If BSD were to catch on for that reason, Kubernetes would be ported to BSD, and the same problem would arise there

View on HN

It's also a 10 years out of date complaint. Btrfs has been stable for fucking ages. That meme needs to die.

Whenever topic of FS arises, I always hear anecdata that btrfs/ext4 lost data and ZFS was smooth sailing.

Yes and not a single one of them can quote someone from this decade because it's a shitty internet myth that won't die.

Also everyone ignores the publicly visible zfs repo/issues. Corruption https://github.com/openzfs/zfs/issues/16631 crash/corruption https://github.com/openzfs/zfs/issues/16626 crash https://github.com/openzfs/zfs/issues/16623 just from this week. One of those filesystems is likely more stable than the other, but the image of perfect zfs is tiring.

> One of those filesystems is likely more stable than the other, but the image of perfect zfs is tiring.

I didn't say perfect, I just said, querying for FS to use, everyone recommends ZFS, over Btrfs. Even if not perfect, it seems to have left a better impression than Btrfs.

fill your btrfs with "dd if=/dev/urandom of=./testfile" as a normal user then "rm ./testfile && sync" then reboot. 6 month ago i could brick btrfs with that "trick".

I have a broken (parent transid verify failed on logical) btrfs RAID5 here that I can't mount anymore even with the recovery commands and google shows many results about it from less than a decade ago.

Hi. Article author here.

I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.

Not myth. Not from t'Internet. Direct personal experience.

Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.

I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.

Yah well. Do some housekeeping then? I mean if the Distro delivers automagically snapshotting in intervals, during installation of packages, or whatever they fancy?

It's not like you'd need those for all eternity. By housekeeping I meant deleting them from time to time, with easily clickable tools, which exist(now/meanwhile), and DO give an overview. Maybe have to 'rebalance' afterwards, which can go wrong if the 'housekeeping' was too late, or something. OTOH the 'rebalancing' can be automated, from the beginning.

I'm sure similar haphazards (regarding common tools like df/du not being able to give an exact overview of remaining capacity) exist under ZFS, at least when your'e using compression.

No. That is the simple answer. I refuse.

I will clean up my own mess. If I take snapshots, it's my job to clean them up.

If the OS does its own then the OS can do the work and clean up its own mess.

More to the point, if the OS's developers thought this was a good idea, then complete the work, finish the job, track the space usage and never ever do operations needing lots of space without checking that space is available or making it available.

This is bad design and bad implementation. It is not my job to fix their omissions.

Yah. Maybe (or even probably, given the history and all the (not even that anecdotical) evidence of all the gotchas and oopsies that happended so far) I'll eat chalk.

But so far I'm really enjoying my new hot technotoy, in combination with some other 'crazy' tools, like zram, profilesync-deamon for the browser, a really 'riced' kernal...err kernel with all sorts of powerful patches, and even most parts of the userland compiled with optimizations to the limits of my cpu, even the browser!

ISTR you mentioned the crappy default partioning suggestions from another OS in another thread, which seem inflexible because of the potential waste of space for different directories like /usr/var/serv/somecrap/whatnotelse/GO/HOME!, which really can't be known in advance for casual desktop-use, and I concure.

But with BTRFS-subvolumes that shit doesn't matter anymore! Whee! :)

I'll wait and see, and will abuse the really unexpectedly well working combination of components and their versions and settings to the max, not having experienced hitches, glitches, or even crashes so far.

But anything which could get lost is backed up incrementally to elsewhere anyways, just in case.

OK, that's perfectly fair. Enjoy! Seriously!

My take is just that, in the 21st century, I do not expect a Linux distro in normal routine use to crash and corrupt its disk. Not _ever._ That was acceptable in the '90s when it was new, but not now.

For the SUSE folks to complain that "U R doin it wrong" doesn't wash.

E.g. for an OS that takes a single-digit number of gigabytes of disk space, a 32GB disk partition should be plenty and it should never fill that up.

I note that recent releases of openSUSE disable Snapper if given a root volume of <= 20GB. Maybe that was due to me and my bug reports. I don't know. It's a rotten answer, though: "OK, this dude's weird usage breaks our snapshot system, so what we'll do is turn it off."

The correct answer is to fix the snapshot system. A better one is to fix the filesystem.

I've had btrfs loose my laptops root filesystem, it just wouldn't mount anymore for no apparent reason. This was ~6 or 7 years ago. Reading the fs with some rescue command worked fine, the ssd continued to work for a few more years after formatting.

I've also had a weird situation after that where a micro SD formatted with btrfs on my desktop PC wouldn't mount on a raspberry pi, and vice-versa the same micro SD formatted on the pi wouldn't mount on the desktop. This was apparently caused by a difference in the used block sizes, which were mutually incompatible.

So I'll quote myself on this.

But also, my server is running a btrfs raid 1 due to the flexibility for resizing and that has been just fine for a few years now. It's not black and white and with backups I am not really worried.

Reply on news.ycombinator.com