WinBtrfs 1.0 Released For Supporting Btrfs On Windows

[duby229]

that's a lie. ntfs on windows is slower than on linux. when i was playing wow it was starting much faster on linux(most time was spent on loading tree of plugins). also windows ntfs on ssd is many times slower than linux nfs (note no t) for tree scanning
maybe for some specific test case like writing one large file windows ntfs will be better than linux ntfs, but who needs that anyway?

It's obvious you have different experiences than me. My experiences with NTFS on windows isn't that bad. And you gotta give Linux some credit, it has a pretty awesome disk cache that is mostly transparent. I bet you some of what you are feeling can be associated with it.

[starshipeleven]

But what I wrote was related to Phoronix benchmarking and you replied to it.

No, no no. It is related to your request for future phoronix benchmarking.

[erendorn]

Given the complexity of btrfs and it's features, it's pretty impressive this project managed to go that far. Kudos.

[Nth_man]

> or Paragon's bullshit ext2-3-4 drivers on Windows.

FWIW, Ext2fsd worked well the last time I used it

http://www.ext2fsd.com/

[arokh]

There is an in-kernel driver for NTFS. It was benched against ntfs3g and it showed ntfs3g was much faster. So FUSE is not an argument. The benchmarks I remember, showed ntfs3g comparable against native Linux filesystems and native Windows NTFS. The main drawback of ntfs3g is the very high CPU utilization.

Just plain wrong. The in-kernel driver is R/O and it's much faster than NTFS3G. A FUSE driver will never beat a native kernel driver, if you have any benchmarks to back your claim up go ahead and post.

[DrYak]

Awesome, except installing it isn't easy and it's unclear how stable it is.

Well, it's BTRFS, what would you expect ?~~

(Runs away, ducking)

Given the complexity of btrfs and it's features, it's pretty impressive this project managed to go that far.

Even more so, as unlike ZFS, BTRFS relies on multiple in-kernel feature for its various part (eg: it calls into Device Mapper code) which WinBTRFS author needed obviously to re-implement from scratch.

also windows ntfs on ssd is many times slower than linux nfs (note no t) for tree scanning

Part of the weirdness is due to the fact that in windows, installable file-system drivers need to re-implement things that we take for granted under a linux kernel.
e.g.: listing and sorting files is implemented by the *driver* in windows (more specifically: glob-pattern matching is done at filesystem driver level).
Imagine if you needed a "ls.btrfs" file as part of "btrfs-tools" and "ls" is simply dispatching to the filesystem's specific "ls.xxxx" (as currently "mount" and "fsck" are doing). That's the level of weirdness you find in Windows.

It also doesn't help that Linux has an excellent cache that even work for network - filesystems (see FS-Cache) whereas Windows' cache is a clusterfuck even local.
There's a reason why linux is so successful on HPC, whereas Windows isn't and licensing cost is only part of it.

WinBtrfs should still work nicely for all other drives (D:, E:, ...) where one can install software on and to keep user files.

Another limitation would be that BTRFS is case-sensitive, whereas Windows isn't (even if it could store case-sensitive filenames on NTFS partitions, it doesn't handle the situation nicely).
Part of the reason why Windows Service for Linux requires a few filesystem drivers to translate trees between win32 and linux containers, and why you should absolutely avoid touching these same files from the other side.


In my experience, the best shared OS partitions are still
- UDF (as long as you do the partition table trick) : log-structured, supported by all desktop OS, supports modern features like several-GB-long files, long filenames, etc. (optionally : access rights and case-sensitive)
- FAT32: aweful piece of shit (filesize < 2 GiB, very crash-prone structure, etc.) but at least universally supported even on embed device (like photo camera).

(And at all possible, steer clear of exFAT : lots of the same drawbacks as FAT32 (except file size) while even less widely supported and patent-encumbered).

[PuckPoltergeist]

Just plain wrong. The in-kernel driver is R/O and it's much faster than NTFS3G. A FUSE driver will never beat a native kernel driver, if you have any benchmarks to back your claim up go ahead and post.

Just plain wrong. The in-kernel driver can be compiled R/W. It's just another config option. And no, I don't have benchmarks. I was speaking about benches that where done years ago. I'm not aware of any actual results. Indeed I doubt anyone is really interested in this, cause ntfs3g is way more feature complete than the in-kernel driver. But that's irrelevant for you. You don't even take into account that a userspace implementation could be done more careful than a kernelspace one. Just a hint: the http server was wiped from the kernel in this moment, when Apache showed it was faster...

[arokh]

Just plain wrong. The in-kernel driver can be compiled R/W. It's just another config option. And no, I don't have benchmarks. I was speaking about benches that where done years ago. I'm not aware of any actual results. Indeed I doubt anyone is really interested in this, cause ntfs3g is way more feature complete than the in-kernel driver. But that's irrelevant for you. You don't even take into account that a userspace implementation could be done more careful than a kernelspace one. Just a hint: the http server was wiped from the kernel in this moment, when Apache showed it was faster...

"The only supported operation is overwriting existing files, without changing the file length."

How many of your write operations fit that profile? Go ahead, try and do something useful RW with that driver.

Repeating something does not make it true. There are no benchmarks showing the FUSE driver being faster, because it isn't. It's science, FUSE/userspace won't be faster than a kernel driver. Years old benchmarks would be even slower, obviously you don't have them because it would be impossible. I'm talking about filesystem drivers here not HTTPD. FUSE is a middle man and needs to translate from userspace into kernel calls. There's unavoidable overhead, and it's factually slower.

[PuckPoltergeist]

I'm talking about filesystem drivers here not HTTPD. FUSE is a middle man and needs to translate from userspace into kernel calls. There's unavoidable overhead, and it's factually slower.

I understand. For something like a webserver, such translations aren't necessary...

[timofonic]

"The only supported operation is overwriting existing files, without changing the file length."

How many of your write operations fit that profile? Go ahead, try and do something useful RW with that driver.

Repeating something does not make it true. There are no benchmarks showing the FUSE driver being faster, because it isn't. It's science, FUSE/userspace won't be faster than a kernel driver. Years old benchmarks would be even slower, obviously you don't have them because it would be impossible. I'm talking about filesystem drivers here not HTTPD. FUSE is a middle man and needs to translate from userspace into kernel calls. There's unavoidable overhead, and it's factually slower.

Did I read about NTFS in kernel? NTFS defused! https://github.com/gzg1984/NTFS-defused