A performance comparison on simple file operations would be cool to see!
See my above reply. Winbtrfs is massively slower on an NVMe drive... but still plenty usable.
Windows on Btrfs
161–170 of 286 posts
Re: Windows on Btrfs
#162Re: Windows on Btrfs
#163Earlier quoted context omitted.
In Linux terms, think about what would happen if you tried to use ACL (or fsattr or whatever non standard stuff) on a filesystem not supporting ACL: it would throw weird errors, and you may not properly handle them if you expected all filesystems to support ACLs.
User land generally doesn’t care about file system specifics. Even in your ACL, example, opening a file would succeed or fail. I suspect this is much more likely to be a secure environment issue. Windows store wants to prevent piracy, there is no way the environment can be trusted because the boot loader wasn’t signed by Microsoft, and therefore may be modified to help people pirate software.
Even if you dont boot with btrfs, the store doesn't even recognize a btrfs partition as a valid drive for apps.
Re: Windows on Btrfs
#164Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer. Surely, given the Linux native file system is open source, adding the ability to mount ext4 partitions natively should be something people can add to Windows? I have seen third party…
Pretty sure there isn’t an ext4 spec, it’s just the reference implementation. Microsoft could build something that is compatible, but keeping compatibility as the reference implementation changes may not be straightforward.
Ext4 was explicitly designed with maintaining backwards and (limited) forwards compatibility in mind precisely for the reason pointed out in my sibling comments.
Depending on the filesystem features you enable, you can even mount an ext4 filesystem with the ext2 kernel driver, and you can already mount an ext2 or ext3 filesystem with the ext4 kernel driver.
A large part of this compatibility is due to the bitmap of compatible, compatible read-only, and incompatible filesystem flags in the filesystem superblock.
For example, when ext4 got support for extents, that's an incompatible feature; you cannot mount an ext4 filesystem with extents with the ext3 kernel driver. This does not even require ext3 to know what an extent is because it's just indicated as an unknown (from the ext3 driver's perspective) incompatibility flag.
On the other hand, the implementation of sparse superblocks (keeping fewer copies of the superblock around to allow for more blocks to be used for file data on filesystems intended to house lots of large files) is merely a read-only compatibility bit; you can mount an ext4 filesystem using sparse superblocks with an ext2/ext3/ext4 driver that does not support them, in a read-only manner. This cannot be mounted read-write because the implementation may try to place a filesystem superblock where file data is supposed to be, which would lead to at best wasted space (negating the feature) or at worst limited filesystem corruption.
When feature changes that could break things are made to the ext4 implementation in the Linux kernel, they are always done so using these (in)compatibility flags, ensuring that only implementations that can entirely support the feature can mount them read-write, and that implementations whose ability to read would not be affected can still mount them read-only. This allows you to create future filesystems (using e.g. mke2fs(8)) and not turn those features on while doing so, if you want the filesystem to be used by other implementations. Something you already have to bear in mind if you're creating a filesystem using a modern mke2fs but intended to be read by ancient Linux kernels.
Re: Windows on Btrfs
#165It's good to see projects like this which basically confirm what we know about the modularity of the filesystem layer in Windows. In fact, the IFS API that enables this has been there since MS-DOS 4: https://en.m.wikipedia.org/wiki/Installable_File_System Although I'm sure that Windows would have some issues with that as XP was the last version that let you boot off of FAT32 I remember it being not too difficult to b…
Linux supports a dozen filesystems and has FUSE for userspace.
It's nice Windows can do things too though I guess.
Re: Windows on Btrfs
#166Awesome. Would love to see some performance marks.
Its not good, see my above posts.
But TBH its like this on linux too. BTRFS is a feature heavy CoW filesystem like ZFS, not a "light," intentionally low overhead fs like ext4 or f2fs (which is what I benched on linux).
Re: Windows on Btrfs
#167Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer. Surely, given the Linux native file system is open source, adding the ability to mount ext4 partitions natively should be something people can add to Windows? I have seen third party…
> Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer. Such projects have long existed, but I suspect there's a lack of interest. It's a difficult technical problem with a narrow usage niche. You need somebody who wants both Windows an…
It might be convenient, but it is also more complex than just being able to read file systems. External disks or partitions containing data in particular will / should always be fully encrypted nowadays, so you'd need interoperability of disk encryption schemes as well (dmcrypt, bitlocker). NAS can handle that transparently.
Re: Windows on Btrfs
#168To me, this article goes a very long way to demonstrate how screwed up people's thinking is in the windows users world.
I mean, let's look at this objectively: the guy is amazed because he actually managed to boot windows off of a non MS-sanctioned software stack.
There's nothing amazing here: these things should be the standard, and it pretty much is the case in the open-source world.
And I certainly don't mean to diminish the technical achievement of the folks who stitched this together, quite the contrary, very nice feat.
But what I'm trying to say: instead of being amazed because they managed to pull it off, they should be demanding this kind of inter-operability between components of the steaming pile of shite that is windows in 2023.
Re: Windows on Btrfs
#169Earlier quoted context omitted.
The Linux audience is software engineers and the companies they who employ them.
So why haven’t such an open source application materialized after all these years?
Well you'd need to fund the cost of a kernel driver signing certificate and get it through WHQL as well. That's just for a start. So this wouldn't be something you could build yourself.
Re: Windows on Btrfs
#170Earlier quoted context omitted.
> Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer. Such projects have long existed, but I suspect there's a lack of interest. It's a difficult technical problem with a narrow usage niche. You need somebody who wants both Windows an…
Wanting to dual-boot sometimes isn't that rare, surely. And local storage for documents remains popular too. It seems to reflect the reality that serious Linux development effort has been very server-focussed for a long time.
Linux has good NTFS drivers. If you want to dual boot and share files, you just make three partitions: Windows (NTFS), Linux (whatever the cool kids are using these days), and Shared Data (NTFS).