Announcement

Collapse
No announcement yet.

VirtIO-FS Sent In For Linux 5.4 With Better Performance Over VirtIO-9P

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

  • VirtIO-FS Sent In For Linux 5.4 With Better Performance Over VirtIO-9P

    Phoronix: VirtIO-FS Sent In For Linux 5.4 With Better Performance Over VirtIO-9P

    VirtIO-FS as a better approach for sharing folders/files with guest VMs is set to debut in Linux 5.4...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Now if only there was a Windows client too.

    Comment


    • #3
      Michael
      also has btter POSIX compliance

      Comment


      • #4
        Originally posted by jacob View Post
        Now if only there was a Windows client too.
        Microsoft has not got setting basic permissions right on linux with virtio-9p > https://github.com/microsoft/WSL/issues/3966

        Let alone the more advanced stuff like posix class acls, LSM xattrs .....

        Making a windows client means having to deal with how posix/linux style of doing things don't match Windows. Microsoft went real Linux kernel with a ext4 partition because they worked out the logic does not align,

        Yes Microsoft NFSv4 usage of ACL does not match the other users of NFSv4 either. Like it or not when it comes to file system stuff Microsoft windows is a special snowflake of incompatible.

        Comment


        • #5
          Originally posted by oiaohm View Post
          Making a windows client means having to deal with how posix/linux style of doing things don't match Windows. Microsoft went real Linux kernel with a ext4 partition because they worked out the logic does not align,
          How about ignore it? I mean - file owner/permissions could be always the same (for example configured in VirtIO-FS/VirtIO-9P options or inherited from parent directory).

          Lack of Linux host - Windows guest sharing possibility - it is the reason why I cannot use KVM/QEMU and I still need to use proprietary solutions like VMware or VirtualBox... There sharing files between Windows guest and Linux host are working just fine (after install proprietary guest tools).

          Workarounds like "install and configure samba on host" are useless. For example VPN connections inside Windows guest forbid access to host network.

          Comment


          • #6
            Storage these days is cheap and computers often come with more ports than you know what to do with. I personally just opt for a dedicated drive for my VMs. That way, you don't have to worry about drivers or additional overhead, in theory (haven't tested this) you could still boot from bare-metal, and you can access the files directly from the host (preferably not while the guest is still running). Any time I'm in need of files that regularly need to be accessed between the host and guest while both are running, I use a NAS. All of this can be done very affordably at home.

            Comment


            • #7
              I've always used the built-in samba server that qemu has.
              Code:
              -net user,smb=/path/to/folder
              . I guess there are probably some use-case where this doesn't provide enough performance, but it's hard for me to imagine.

              Comment


              • #8
                Originally posted by Danniello View Post
                How about ignore it? I mean - file owner/permissions could be always the same (for example configured in VirtIO-FS/VirtIO-9P options or inherited from parent directory).
                Except that does not exactly work. Applications like to look a permissions and use file system locking. When those things don't work out how applications expect the applications can crash taking the last 10 to 15 mins of work with it(if you save regularly not depend on the auto backup that is likely screwed up by permissions and locking not running right).

                Originally posted by Danniello View Post
                Lack of Linux host - Windows guest sharing possibility - it is the reason why I cannot use KVM/QEMU and I still need to use proprietary solutions like VMware or VirtualBox... There sharing files between Windows guest and Linux host are working just fine (after install proprietary guest tools).
                I normally use the -net user,smb solution.

                Originally posted by Danniello View Post
                Workarounds like "install and configure samba on host" are useless. For example VPN connections inside Windows guest forbid access to host network.
                Normally I have the host using namespaces and running the VPN in the Linux system. Linux better network stack equals better thoughput than even letting windows do it on bare metal.

                Comment


                • #9
                  Originally posted by AndyChow View Post
                  I've always used the built-in samba server that qemu has.
                  Code:
                  -net user,smb=/path/to/folder
                  . I guess there are probably some use-case where this doesn't provide enough performance, but it's hard for me to imagine.
                  Samba has issues when it comes to mapping permissions. It's also worth noting that you need to install Samba to use this option. If VirtIO-FS is in the kernel, I assume it will be much better in every possible way.

                  Comment


                  • #10
                    Originally posted by DoMiNeLa10 View Post

                    Samba has issues when it comes to mapping permissions. It's also worth noting that you need to install Samba to use this option. If VirtIO-FS is in the kernel, I assume it will be much better in every possible way.
                    You're right. I always assumed no samba installation was required. From Arch's wiki: "QEMU's documentation says it has a "built-in" SMB server, but actually it just starts up Samba with an automatically generated smb.conf file located in /tmp/qemu-smb.random_string and makes it accessible to the guest at a different IP address (10.0.2.4 by default). This only works for user networking, and is useful when you don't want to start the normal Samba service on the host, which the guest can also access if you have set up shares on it."

                    Glad I learned something today.

                    Comment

                    Working...
                    X