On Mon, Apr 11, 2022 at 03:20:05PM +0200, Bernd Schubert
wrote:>
>
> On 4/11/22 13:54, JeffleXu wrote:
> >
> >
> > On 4/11/22 7:52 PM, Vivek Goyal wrote:
> > > On Mon, Apr 11, 2022 at 10:10:23AM +0800, JeffleXu wrote:
> > > >
> > > >
> > > > On 4/8/22 8:06 PM, Vivek Goyal wrote:
> > > > Curiously, why minimum 1 range is not adequate? In which
case minimum 2
> > > > are required?
> > >
> > > Frankly speaking, right now I don't remember. I have vague
memories
> > > of concluding in the past that 1 range is not sufficient. But if
you
> > > like dive deeper, and try with one range and see if you can
introduce
> > > deadlock.
> > >
> >
> > Alright, thanks.
> >
>
>
> Out of interest, how are you testing this at all? A patch from Dharmendra
> had been merged last week into libfuse to let it know about flags2, as we
> need that for our patches. But we didn't update the FLAGS yet to add in
DAX
> on the libfuse side.
>
> Is this used by virtio fs?
Yes, idea is that this is used by virtiofs. Now looks like there are
multiple implementations of virtiofs daemon and they are either not
using libfuse or have forked off libfuse or created a new libfuse
equivalent in rust etc. So as fuse kernel gets updated, people are
updating their corresponding code as need be.
For example, we have C version of virtiofsd in qemu. That has taken
code from libfuse and built on top of it. BTW, C version of virtiofsd
is deprecated now and not lot of new development is expected to take
place there.
Then there is rust version of virtiofsd where new development is taking
place and which is replacement of C virtiofsd.
https://gitlab.com/virtio-fs/virtiofsd
This does not use libfuse at all.
And I think other folks (like developers from Alibaba) have probably
written their own implementation of virtiofsd. I am not sure what
exactly are they using.
I see there is rust crate for fuse.
https://crates.io/crates/fuse
And there is one in cloud-hypervisor project.
https://github.com/cloud-hypervisor/fuse-backend-rs
> Or is there another libfuse out there that should
> know about these flags (I think glusterfs has its own, but probably not
> using dax?).
>
So server side of fuse seem to be all fragmented to me. People have
written their own implementations based on their needs.
> Also, testing is always good, although I don't see how Jeffs patch
would be
> able break anything here.
Agreed. I worry about testing constantly as well. qemu version of
virtiofsd does not have DAX support yet. Rust version DAX support is
also minimal.
So for testing DAX, I have to rely on out of tree patches from qemu
here if any changes in virtiofs client happen.
https://gitlab.com/virtio-fs/qemu/-/tree/virtio-fs-dev
Jeffle is probably relying on their own virtiofsd implementation for DAX
testing.
Thanks
Vivek