lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190212185725.GD6273@redhat.com>
Date:   Tue, 12 Feb 2019 13:57:25 -0500
From:   Vivek Goyal <vgoyal@...hat.com>
To:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, miklos@...redi.hu, stefanha@...hat.com,
        dgilbert@...hat.com, sweil@...hat.com, swhiteho@...hat.com
Subject: Re: [PATCH 00/52] [RFC] virtio-fs: shared file system for virtual
 machines

On Tue, Feb 12, 2019 at 09:26:48PM +0530, Aneesh Kumar K.V wrote:
> Vivek Goyal <vgoyal@...hat.com> writes:
> 
> > Hi,
> >
> > Here are RFC patches for virtio-fs. Looking for feedback on this approach.
> >
> > These patches should apply on top of 4.20-rc5. We have also put code for
> > various components here.
> >
> > https://gitlab.com/virtio-fs
> >
> > Problem Description
> > ===================
> > We want to be able to take a directory tree on the host and share it with
> > guest[s]. Our goal is to be able to do it in a fast, consistent and secure
> > manner. Our primary use case is kata containers, but it should be usable in
> > other scenarios as well.
> >
> > Containers may rely on local file system semantics for shared volumes,
> > read-write mounts that multiple containers access simultaneously.  File
> > system changes must be visible to other containers with the same consistency
> > expected of a local file system, including mmap MAP_SHARED.
> >
> > Existing Solutions
> > ==================
> > We looked at existing solutions and virtio-9p already provides basic shared
> > file system functionality although does not offer local file system semantics,
> > causing some workloads and test suites to fail.
> 
> Can you elaborate on this? Is this with 9p2000.L ? We did quiet a lot of
> work to make sure posix test suite pass on 9p file system. Also 
> was the mount option with cache=loose?

Hi Aneesh,

Yes this is with 9p2000.L and cache=loose. I used following mount option.

mount -t 9p -o trans=virtio hostShared /mnt/virtio-9p/ -oversion=9p2000.L,posixacl,cache=loose

We noticed primarily two issues.

- Ran pjdfstests and a lot of them are failing. I think even kata
  container folks also experienced pjdfstests failures. I have never
  looked into details of why it is failing.

- We thought mmap(MAP_SHARED) will not work with virtio-9p when two
  clients are running in two different VMs and mapped same file with
  MAP_SHARED.

Having said that, biggest concern with virtio-9p seems to be performance.
We are looking for ways to improve performance with virtio-fs. Hoping
DAX can provide faster data access and fuse protocol itself seems to
be faster (in primilinary testing results).

Thanks
Vivek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ