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
