Btrfs driver for windows?

[acolomb]

Hi all!

There have been quite some articles and posts about the Btrfs file system lately. It seems to be gaining a lot of momentum and adoption in Linux distributions.

Now my question is: How about the MS Windows support?

I still have two or three Windows versions on my computers in dual-boot configuration (in addition to running VirtualBox, which is quite a nice solution). Accessing files from both Linux and Windows operating systems has become quite difficult over the past few years. There are three feasible solutions I know of:

1. FAT32 - Has been supported in Linux for decades now and is the de-facto standard on USB storage devices. Big limitations: File size, case insensitivity and access rights. Though the latter is not really important on USB sticks. Aside from that, it's obsolete...

2. NTFS - With the ntfs-3g driver it works quite nicely out of the box on most Linux distributions now. However, the support is still based on reverse engineering. File size limits are no longer a problem, but the access permissions just don't map between the two worlds and case is also still an issue. I personally don't trust the Windows security implementation as much as the traditional UNIX access rights (in conjunction with ACLs nowadays). And even if it were mappable, there seems to be no documentation about the security models within NTFS.

3. ext2/3/4 - This is what I have been using the last couple of years for any dual-boot configuration. There is the Windows Ext2 IFS driver which also supports ext3 to some extent. Big problems: No journalling on ext3 and it does not support inode sizes > 128 bytes. For some time now, the default inode size when creating ext3 file systems has been 256 bytes. So even if one manages to create a separate data partition and format it to ext3, it's not trivial to figure out why it doesn't work with Ext2 IFS. Or even to know what an inode size is and how to tell mke2fs the right one to use. Having copied Gigabytes of data to the new FS and then noticing the only way to access it from Windows is re-formatting, that's a no-go for inexperienced users wanting to switch to a Linux distribution (like my Dad did, fortunately). The Ext2 IFS project looks rather dead, the last release is 1,5 years old and there don't seem to be any plans concerning these limitations. Not even to mention ext4 support. I am aware of a few commercial ext2/3/4 drivers for Windows, but aside from the licensing, the architecture doesn't seem as sane as with Ext2 IFS.

Enter Btrfs.

With it having a chance to be the default file system in many upcoming distro releases, this is another step further away from Windows / Linux filesystem compatibility. Ext4 as the current default is not an option either, but with the current developments, I would think a nice Btrfs driver would be the better way to go.

This is all not just concerning dual-boot configurations, but think USB mass storage devices? Having a small FAT32 partition with an installable driver and a large Btrfs data partition on a USB hard disk would be sufficient to use it in different environments where so far the only options were FAT and NTFS. Provided one has administrative rights on the Windows boxes

Maybe there is potential here for an article questioning the future plans, if anybody has any?

Kind regards and thanks Michael for all the nice posts and stories!
Andre

[loonyphoenix]

Not a driver per se, but a reasonable option is to use coLinux. I've managed to access ext4 partitions just fine from Windows, and I don't see why btrfs, or really any filesystem supported by the linux kernel of the latest release (.33.5, as of the time of writing of this post). The summary of steps necessary to do this are:

1). Download and install coLinux.
2). Install your distro of choice with most things stripped away, leaving only the bare necessities to work with the filesystem and samba. (Arch Linux base group + samba package and dependencies works for me, but I'm sure you can make the distro even smaller.)
3). Set up a network connection between coLinux and Windows.
4). Set up forwarding of the hard disk partitions that you want to access from Windows to coLinux.
5). Mount those partitions in coLinux and set up samba to share their contents over the virtual network.
6). Set up coLinux to work as a Windows service.
7). Set up auto-mounting of coLinux samba shares.

The results are reasonably good. The pros of this method are:
1). The filesystems are accessed by a native Linux driver, which means no file corruption by faulty Windows drivers.
2). You can access any filesystem the Linux kernel or FUSE supports.
The cons are:
1). Non-trivial to set up. The process is manual and requires knowledge of inner workings of both Linux and Windows.
2). Large resources consumption. While running a stripped Arch system doesn't require much memory (64 MB is even excessive, but I can spare them for buffering and caching purposes), the CPU is taxed rather severely.
3). Low speeds. As a comparison, Ext2IFS gave me ~19 MB/s (seems to be my drive's physical limit) at 10% of CPU consumption, while coLinux game me ~5 MB/s at 40% CPU consumption.

Cheers.

[saulius2]

Nice ideas with regard both to acolomb and loonyphoenix.

If ZFS was started being ported into Windows:

http://code.google.com/p/zfs-win/

...then BTRFS could go for it also.

OTOH, has anyone tried using exFAT (FAT64) on Linux? eg.:

http://code.google.com/p/exfat/

[droidhacker]

I wouldn't let a wondoze within 500 feet of a linux filesystem.

First step you should take;
DELETE THE WONDOZE.

And then the problem will be solved. No need to be compatible with something that doesn't exist.

[loonyphoenix]

@droidhacker: I'm all for deleting Windows Unfortunately, it's not completely realistic to expect to get rid of it globally, so interoperability is important. And since MS unfortunately don't give a flying fuck about interoperability, it's up to other OSes to provide it.

[acolomb]

Thank you loonyphoenix for your ideas. coLinux is something I had never heard of before, but the general idea definitely works well.

In another setup, I use a minimal Debian installation under VirtualBox to access a software RAID-1 configuration with ext3 filesystems and export it via samba. Works alright, but it's really a lot of overhead, administrative and performance-wise.

coLinux seems a little less bloated than that, but still a native Windows driver would be nice. Especially for the USB flash drive use case, a second, dedicated operating system running in the background seems hardly feasible.

Andre

[chithanh]

Another possibility is using UDF. Up to version 2.01 it has read and write support by all modern operating systems.