Announcement

Collapse
No announcement yet.

WinBtrfs 1.0 Released For Supporting Btrfs On Windows

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by pal666 View Post
    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.

    Comment


    • #22
      Originally posted by sdack View Post
      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.

      Comment


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

        Comment


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

          FWIW, Ext2fsd worked well the last time I used it
          http://www.ext2fsd.com/

          Comment


          • #25
            Originally posted by PuckPoltergeist View Post
            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.

            Comment


            • #26
              Originally posted by cl333r View Post
              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)

              Originally posted by erendorn View Post
              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.

              Originally posted by pal666 View Post
              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.

              Originally posted by sdack View Post
              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).

              Comment


              • #27
                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.
                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...

                Comment


                • #28
                  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...
                  "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.
                  Last edited by arokh; 09-11-2017, 06:06 AM.

                  Comment


                  • #29
                    Originally posted by arokh View Post
                    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...

                    Comment


                    • #30
                      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.
                      Did I read about NTFS in kernel? NTFS defused! https://github.com/gzg1984/NTFS-defused

                      Comment

                      Working...
                      X