Awesome. Would love to see some performance marks.
Windows on Btrfs
21–30 of 286 posts
Re: Windows on Btrfs
#22Interesting, 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.
>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.
Re: Windows on Btrfs
#23I'm intending to write up some docs and announce it in the next few days, but since this thread is here, I might as well mention it now:
On the topic of alternative btrfs implementations, I've been working on https://git.lukeshu.com/btrfs-progs-ng/ which is written entirely in Go.
Its `btrfs-rec inspect mount --pv=/dev/whatever` is a read-only FUSE implementation of btrfs that is more fault-tolerant (of corrupt filesystems) than the normal in-kernel btrfs driver (and even more tolerant than `btrfs rescue` or `btrfs recover`).
It's still missing a bit; RAID almost certainly doesn't work, and encryption is not implemented. But hopefully some folks will find it useful, or at least neat!
Oh, comparison with the existing https://github.com/adam900710/btrfs-fuse : (1) Again, mine has better fault tolerance, (2) but mine is read-only, (3) mine supports xattrs (TODO in Adam's), (4) mine supports separate inode address spaces for subvolumes (Adam's doesn't due to limitations in FUSE, mine works around this by lazily setting up separate mountpoints for each subvolume).
Re: Windows on Btrfs
#24Interesting, 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.
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 snuf…
> `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.
Re: Windows on Btrfs
#25Can someone please explain the advantages of doing this?
This is a science experiment.
Re: Windows on Btrfs
#26Interesting, 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.
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 snuf…
Any ideas on what causes the docker issue? Or have you not poked it with a stick yet?
Re: Windows on Btrfs
#27Whoa. So why didn’t the Windows store work? Some kind of trusted environment thing?
Re: Windows on Btrfs
#28Interesting, 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.
File systems are drivers and user space software shouldn’t really see the difference.
Re: Windows on Btrfs
#29Earlier quoted context omitted.
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 snuf…
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...
Re: Windows on Btrfs
#30Earlier quoted context omitted.
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 snuf…
> `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...