Originally posted by pal666
View Post
Announcement
Collapse
No announcement yet.
WinBtrfs 1.0 Released For Supporting Btrfs On Windows
Collapse
X
-
-
Originally posted by PuckPoltergeist View PostThere 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.
- Likes 1
Comment
-
Originally posted by cl333r View PostAwesome, except installing it isn't easy and it's unclear how stable it is.
(Runs away, ducking)
Originally posted by erendorn View PostGiven the complexity of btrfs and it's features, it's pretty impressive this project managed to go that far.
Originally posted by pal666 View Postalso windows ntfs on ssd is many times slower than linux nfs (note no t) for tree scanning
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.
Originally posted by sdack View PostWinBtrfs should still work nicely for all other drives (D:, E:, ...) where one can install software on and to keep user files.
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).
Comment
-
Originally posted by arokh View Post
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.
Comment
-
Originally posted by PuckPoltergeist View 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...
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.Last edited by arokh; 11 September 2017, 06:06 AM.
Comment
-
Originally posted by arokh View PostI'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.
Comment
-
Originally posted by arokh View Post
"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.
Comment
Comment