On 07.05.20 16:29, Miklos Szeredi wrote: > On Thu, May 7, 2020 at 2:18 PM Max Reitz <[email protected]> wrote: >> >> On 07.05.20 13:43, Miklos Szeredi wrote: >>> On Thu, May 7, 2020 at 12:56 PM Max Reitz <[email protected]> wrote: >>>> >>>> On 06.05.20 18:04, Dr. David Alan Gilbert wrote: >>>>> * Max Reitz ([email protected]) wrote: >>>>>> Whenever we encounter a directory with an st_dev that differs from that >>>>>> of its parent, we set st_rdev accordingly so the guest can create a >>>>>> submount for it. >>>>>> >>>>>> Make this behavior optional, so submounts are only announced to the >>>>>> guest with the announce_submounts option. Some users may prefer the >>>>>> current behavior, so that the guest learns nothing about the host mount >>>>>> structure. >>>>>> >>>>>> Signed-off-by: Max Reitz <[email protected]> >>>>> >>>>> Does this need to be wired to a flag in the INIT message (like say >>>>> FUSE_ASYNC_READ) to indicate that the kernel/daemon supports this, or is >>>>> it really safe just to start sending the changed rdev? >>>> >>>> I supposed it to be safe, given that rdev is never used for anything but >>>> device files, so basically it was just a reserved field for directories. >>> >>> You assume only directories can be mounted, but that's not so. A >>> device can also be the source or destination of a bind mount. >> >> Well, I mostly thought this case wouldn’t be too important. But I >> suppose it doesn’t make sense to decide now that it’s never going to be >> important. >> >>> We need to extend fuse_entry_out with a flags field. We could >>> possibly reuse the upper bits of entry_valid (i.e. timeouts above say >>> INT_MAX seconds could be taken as "infinity"). Unfortunately that's >>> not as easy as splitting it into two fields due to endianness :( >> >> For the time being, a single bit would be sufficient to signify whether >> there should be a submount at all. We could add a field with a submount >> ID (i.e., st_dev from the host) in the future when we decide we >> want/need to ensure that two inodes with the same st_dev on the host >> also have the same st_dev in the guest. > > Hmm, do we need a separate bit, then? Couldn't the kernel decide > based on st_dev whether a new submount is needed? I.e. return root > st_dev in INIT reply, store it in root fuse_mount and lookups compare > attr.dev to fm->st_dev.
That was the idea, but there is no fuse_attr.dev, which is why I (ab)used fuse_attr.rdev instead. Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
