Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows on Btrfs

lilysthings.org

Post reply on HN
Print view View original

41–50 of 286 posts

Re: Windows on Btrfs

#41

Post by pxc »

LukeShu wrote: post #29
jdhendrickson wrote: post #26

Earlier quoted context omitted.

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.

Re: Windows on Btrfs

#42

Post by yjftsjthsd-h »

csdvrx wrote: post #12
skanga wrote: post #6

Can someone please explain the advantages of doing this?

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.

> Linux running on NTFS with the new kernel driver.

As the root file system? Does that work?

Re: Windows on Btrfs

#43

Post by chmod775 »

qbasic_forever wrote: post #16

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!

Given there's now native NTFS support in the Linux kernel, you could also do that that the other way around.

Re: Windows on Btrfs

#46

Post by c7DJTLrn »

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.

Re: Windows on Btrfs

#47

Post by Rimintil »

speed_spread wrote: post #3

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.

This is due to file system filter [drivers], not the file system. NTFS is perfectly fine and performs well.

Re: Windows on Btrfs

#48

Post by ilyt »

c7DJTLrn wrote: post #46

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 o…

I did that for lulz few times in Linux when I didn't wanted to fuck up with some old server's boot when I was decommissioning it.

Just make a big file in /dev/shm, add it via loopback to LVM and migrate system partition on it, then run shred on drives without the annoying messages kernel screams when it has its storage destroyed underneath

Re: Windows on Btrfs

#50

Post by dontlaugh »

solarkraft wrote: post #31
Arnavion wrote: post #22

Earlier quoted context omitted.

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 save…

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.
Post reply on HN