[HN Gopher] Windows on Btrfs
___________________________________________________________________
 
Windows on Btrfs
 
Author : susam
Score  : 110 points
Date   : 2023-04-21 21:08 UTC (1 hours ago)
 
web link (www.lilysthings.org)
w3m dump (www.lilysthings.org)
 
| qbasic_forever wrote:
| Haha wow that is so ridiculous it's awesome. Seeing both the
| Linux root and Windows root with Program Files living right next
| to usr, etc. is _wild_. Very cool hack!
 
  | chmod775 wrote:
  | Given there's now native NTFS support in the Linux kernel, you
  | could also do that that the other way around.
 
| biorach wrote:
| I highly recommend the Windows BTRFS driver.
 
  | remram wrote:
  | Recommend it for what?
 
| speed_spread wrote:
| Too bad the article doesn't talk about performance vs NTFS. Any
| quick and dirty comparative benchmark would have been nice. But
| then again, If BTRFS had been slower than NTFS it could have been
| due to a suboptimal (re)implementation.
 
  | rbanffy wrote:
  | I think nothing these days can perform worse than NTFS. I've
  | been using Windows on my corporate issue laptop and anything
  | that includes disk IO is a huge pain.
 
    | kitsunesoba wrote:
    | Some amount of that might be coming from Windows Defender and
    | similar, but yeah NTFS isn't exactly a speed demon.
 
      | garaetjjte wrote:
      | Nothing particularly wrong with NTFS, it's Windows
      | filesystem architecture that is slow.
 
        | solarkraft wrote:
        | I can't find it right now, but I believe there was a talk
        | from a Rust maintainer a while ago about the Rust
        | installation being way slower than it should be, which
        | was almost entirely a rant on Windows file system
        | performance.
 
        | ygra wrote:
        | That one perhaps?
        | https://www.youtube.com/watch?v=qbKGw8MQ0i8
        | 
        | I don't recall it particularly ranty, though.
 
| Dwedit wrote:
| So how reliable is this and how long will it take before you get
| a badly corrupted disk?
 
| c7DJTLrn wrote:
| Speaking of Windows storage drivers, years ago, I managed to get
| Windows to boot and run entirely in RAM using some fairly obscure
| tools from the reboot.pro forums. I always wanted to have an
| immutable Windows system that I could manage like cattle.
| Unfortunately, setting up such a system was extremely complicated
| and a manual process. I am aware that Windows now has a driver
| called UWF that functions a bit like an overlay filesystem and
| can create ephemeral overlays, but it's not quite the same as
| booting and running in RAM. It's also only available in
| Enterprise unless you enable it via registry edits.
 
| nwellinghoff wrote:
| Awesome. Would love to see some performance marks.
 
| dmitrygr wrote:
| Nobody asked for this, wanted this, or imagined it. But it was
| done and it is epic! A tip of my hat!
 
| LukeShu wrote:
| I'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).
 
| kitsunesoba wrote:
| 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.
 
  | LukeShu wrote:
  | 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.
 
    | Slix wrote:
    | > `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.
 
      | LukeShu wrote:
      | 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...
 
    | jdhendrickson wrote:
    | Any ideas on what causes the docker issue? Or have you not
    | poked it with a stick yet?
 
      | LukeShu wrote:
      | 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...
 
        | pxc wrote:
        | 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.
 
  | yyyk wrote:
  | 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.
 
  | pxc wrote:
  | 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!
 
  | curt15 wrote:
  | >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.
 
    | Arnavion wrote:
    | 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.
 
      | solarkraft wrote:
      | 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.
 
  | nailer wrote:
  | File systems are drivers and user space software shouldn't
  | really see the difference.
 
  | LanternLight83 wrote:
  | 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.
 
| skanga wrote:
| Can someone please explain the advantages of doing this?
 
  | rbanffy wrote:
  | It forces you to understand how Windows functions on unexpected
  | conditions and that knowledge can be extrapolated to other
  | situations where something on Windows fails for no apparent
  | reason and you just know it because you saw it before.
  | 
  | Do not underestimate the power of arcane knowledge.
 
  | HeckFeck wrote:
  | Step one: Include Linux kernel in Windows.
  | 
  | Step two: Include Linux filesystem in Windows.
  | 
  | Step three: Windows is Linux.
 
  | dgunay wrote:
  | During my transition period from Windows to Linux, I stored the
  | majority of my games on my NTFS drive because it was much
  | bigger and I wanted them available on Windows in case they
  | didn't work on Proton. I could play them from Linux with
  | ntfs-3g but some of them would just refuse to launch unless I
  | moved them a non-NTFS drive. Maybe they would've worked in this
  | scenario? Hard to say.
 
  | xaduha wrote:
  | This is a science experiment.
 
  | solarkraft wrote:
  | Less Microsoft-centric stuff on your computer.
  | 
  | btrfs is pretty comfortable to manage, too.
  | 
  | On that point: I wonder how the subvolume experience is.
 
  | seiferteric wrote:
  | Actually I have been looking for just this for several years,
  | even as recently as a few weeks ago I was looking, but only
  | found some commercial btrfs driver. The idea of unified storage
  | is really nice, you don't have to decide how much each OS gets,
  | and with btrfs you can just plop in another drive and extend
  | onto it to transparently increase storage capacity. On top of
  | that, tings like duplicating steam game assets would probably
  | be a big win.
 
  | csdvrx wrote:
  | Why keep different filesystems outside of specific performance
  | needs? I've experimented with weirder things, like Linux
  | running on NTFS with the new kernel driver.
 
    | yjftsjthsd-h wrote:
    | > Linux running on NTFS with the new kernel driver.
    | 
    | As the root file system? Does that work?
 
| solarkraft wrote:
| Pretty cool, apart from the fact that it's Windows you're
| booting.
| 
| But what's up with UWP apps not working?
 
| EvanAnderson wrote:
| This is really cool and speaks to the modularity of the Windows
| file system stack. I love projects that customize Windows
| (working against its closed-source nature).
| 
| There's an OpenZFS port to Windows[0]. I wonder if my hopes of
| having ZFS on Windows (including the boot drive, because I would
| love to be able to snapshot and rollback) would actually be
| possible.
| 
| [0] https://github.com/openzfsonwindows/openzfs
 
| AshamedCaptain wrote:
| I am sure this will break the second time you run Windows Update.
 
  | csdvrx wrote:
  | > I am sure this will break the second time you run Windows
  | Update.
  | 
  | Then you are confidently wrong, because Windows Update rarely
  | (if ever) touches the bootloader, while this is the main
  | innovation of the WinBTRFS project.
 
  | easton wrote:
  | I wouldn't be so sure, Windows is famously annoying to goof
  | with the boot loader on from a running install. You usually
  | need to boot from another system to fix/reinstall it (at least,
  | you did last time I needed to bring back the Windows bootloader
  | on a borked dual boot).
  | 
  | Although, since UWP doesn't work it's a moot point, that means
  | you probably can't run Windows Update.
 
| nailer wrote:
| Whoa. So why didn't the Windows store work? Some kind of trusted
| environment thing?
 
| rbanffy wrote:
| A more sensible approach would be to have a separate data volume
| to store important stuff on and leave it as BtrFS while letting
| Windows and Windows software run off NTFS.
| 
| But, then, what'd be the fun of having a computer you don't need
| to fix?
 
___________________________________________________________________
(page generated 2023-04-21 23:00 UTC)