Hacker News Reader

Comment by kitsunesoba | Hacker News Reader

Interesting, I would've expected more Windows software to just assume NTFS with some fallbacks for (ex)fat given how there haven't really been any other options for quite some time.

How stable is Btrfs these days? Remember reading years ago that it was bad about spontaneously corrupting itself for no apparent reason.

Curious if something similar is possible with ZFS.

View on HN

IMO, it became stable somewhere between 2013 and 2016. I definitely haven't had any spontaneous corruption since at least 2016 (on multiple laptops and servers; btrfs volumes that mid-double-digit of terabytes)

That said,

- My BDB and SQLite databases tend to corrupt if my laptop battery dies and they're on a volume that's not on LUKS.

- `btrfs check` (fsck), `btrfs rescue`, and `btrfs restore` are IMO not up to snuff if you do encounter corruption (caused by something else, like a failing drive). (But I'm working on that https://git.lukeshu.com/btrfs-progs-ng/ !)

- `docker build` is weirdly slow on btrfs, I always set up a separate ext4 `/var/lib/docker` volume.

- I do RAID and encryption separately in MD or LVM and LUKS, so no comments from me about the stability of btrfs' built-in RAID cor encryption.

> `docker build` is weirdly slow on btrfs, I always set up a separate ext4 `/var/lib/docker` volume.

I'm currently doing this for a different reason. My docker builds started failing after some Ubuntu upgrade. I gave up and used ext4 for that docker directory to fix everything. https://serverfault.com/q/1127148

It unsettled me because now I'm not sure whether btrfs (or docker with btrfs) is production-ready.

Docker has 8 different storage drivers that it can use... that's a lot, so you know they don't all get equal attention. As much as I love btrfs, it's probably fair to say that the only Docker storage driver that receives adequate attention to be production-ready is "overlay2".

https://docs.docker.com/storage/storagedriver/select-storage...

Any ideas on what causes the docker issue? Or have you not poked it with a stick yet?

I haven't had a chance to dig in to it yet. Most of the time, Docker uses `overlayfs` to emulate COW, but on btrfs it can just use the filesystem's native COW. In my mind it's about equally likely that it's Docker's fault as it is btrfs's fault; that perhaps Docker's btrfs storage driver is doing something dumb.

https://docs.docker.com/storage/storagedriver/select-storage...

For VMs and containers isn't it pretty common to use a subvol where CoW is disabled for their disk images? Same thing for ZFS with datasets that disabled CoW for things like that.

> Same thing for ZFS with datasets that disabled CoW for things like that.

Does ZFS let you disable CoW?

Huh. Looks like it doesn't! I knew that BTRFS did and saw that it was on the roadmap for bcachefs, and assumed it was something you could tweak in ZFS as well.

>How stable is Btrfs these days? Remember reading years ago that it was bad about spontaneously corrupting itself for no apparent reason.

On one hand, Fedora and SUSE default to Btrfs. On the other hand, data corruption bugs are still being unearthed [1]:

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2169947.

FWIW I've been using btrfs for the root partition for a decade without any (observed) corruption problems. This is across multiple installs of OpenSUSE Tumbleweed on laptops and PCs, HDDs and SSDs and most recently an SD card. Back in the day it needed manual intervention to rebalance but that is automated now. Also, OpenSUSE's update program automatically takes pre- and post- snapshots, and these snapshots have saved me a lot of headache from botched upgrades.

Same here. Never had to do anything, with the notable exception of it being somewhat annoying to recover when the disk is full (which is why I've started to keep subvolumes that I can quickly delete).

But I'm not running a RAID, which I believe is where almost all of the data corruption has happened.

I’ve settled on unraid with btrfs partly for that reason.

I've had corruption on a btrfs root partition somewhere between last year and only this year.

It was in files I wasn't really using anymore (some ssh key files on vps that weren't online anymore) so I have no idea when it really occured.

File systems are drivers and user space software shouldn’t really see the difference.

There is no way to have btrfs caps insensitive. So some software (poorly coded) could have capitalization issues that would not appear in NTFS that would in btrfs. But other than that I believe you are right (barring utilities specifically designed to interact with FS attributes)

> There is no way to have btrfs caps insensitive.

There is no way to make NTFS case insensitive either, it being case insensitive in Windows is a Windows implementation detail.

Does that mean windows could make any file system case insensitive?

Any OS can "make a filesystem case insensitive"; for example in Linux you can do it if your kernel has support for it[1].

But again, that is a OS implementation detail thing, the underlying file system is still case preserving.

[1] https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...

I've been running my Samba shares case sensitive for over a decade, only issue I've found is I can't rename "Foo" to "foo" without jumping through an extra hoop (add a letter or similar).

Perhaps if I ran some software off it I might find some more issues but, overall quite little. The difference in speed is immense though.

Well, there's ReFS as well. That experience suggests there are issues that the author might come up against following boot: Case insensitive lookup (NTFS has the option for case sensitive subdirectories but that probably doesn't matter), Mark of the Web/SQL Server (Alternate data streams support), UWP/Microsoft Store apps support (IIRC requires FS encryption support via a specific interface), DLT (Object IDs), getting DISM to work for updates... It's cool to get this far, full support will probably need a bit more work.

I enjoy it as ext4++. Would I trust it for RAID? Not particularly. There seems to be a decent amount of foot-guns still and I would greatly prefer just using ZFS.

Granted, I do trust Synology using btrfs but they are also subject matter experts on the topic.

Synology doesn’t use btrfs in raid mode either. They put it on top of their LVM-based RAID instead.

I thought I heard that as well but I had another person disagree so I’m not sure who is right.

They are mistaken. In Synology DSM you create a "pool" which is LVM-based under the hood, then inside the pool you can add btrfs & ext4 "volumes" that coexist inside the pool. They would need to let you create a btrfs pool instead if they were doing btrfs on bare drives.

There's a ZFS port for Windows but I don't think using it on the boot volume is supported. You could definitely try it, though!

It's really matured, and although the RAID5/6 Write Hole still exists, I wouldn't reccomend a ZDEV over RAID10 either, which is what I believe offers the best tradeoffs for most users on both filesystems. Love the flexibility that BTRFS provides via eg. the balance comand, and Snapper is great for snapshot management.

Synology apparently thinks btrfs is reliable enough to bet their credibility on it, for what that's worth.

Reply on news.ycombinator.com