On Dienstag, 7. Mai 2019 13:57:56 CEST Daniel P. Berrangé wrote: > > ... > > <filesystem type='mount' accessmode='mapped'> > > > > <source dir='/vm/fs'/> > > <target dir='root'/> > > <important path='/var/shares'/> > > <important path='/tmp'/> > > > > </filesystem> > > > > </devices> > > > > </domain> > > > > Like with the vii qemu virtfs command line argument, the order of the > > "important" tag defines which one gets the highest inode namespace > > (smallest generated suffix) on guest side. > > Do we think anyone is likely to use this feature in the real world ?
I don't know if other people need it, that's one of the reasons why I am asking for a coarse high level feedback of the current v3 patch set before getting into the details. The only thing I can say right now is that I must use this feature when running Samba to avoid all kinds of serious problems. And I could imagine inode namespace control to become more of an issue once nested virtualization becomes more popular. > I'm not really a fan of the representation, because this is affecting > guest ABI via a side effect of the ordering which is the kind of thing > that has got us in trouble before. If we need control over the IDs > used for each mount point, then I tend to think we need to represent > it explicitly such that the mgmt app sets the exact ID used. > > <pathid dir="/var/shares" id="0x1"/> > <pathid dir="/tmp" id="0x3"/> > > this ensures that the IDs are still stable when adding or removing > paths Well, that would lead to the exact opposite of what you asked for. Because allowing admins to configure an exact ID (which I think you mean should be used as exact inode suffix by 9p then) would expose implementation details inside 9pfs to config space, which are subject to change, might collide with implementation details, and requires implementation knowledge and extreme care by admins so they would pick appropriate IDs with "suffix-free" property which are guaranteed to create unique numbers in all cases: https://en.wikipedia.org/wiki/Prefix_code Also keep in mind that one fs device might end up having multiple suffixes. Hence my suggestion was to only expose the bare minimum to config space regarding this issue: Asking (if required at all) admins which ones are the most critical pathes regarding inode namespace for their use cases, and 9p would then automatically generate appropriate suffixes for those mentioned by admin to achieve the highest inode namespace appropriately and in a safe way. Plus for the "important path=" semantics I suggested you don't have have to use mount points BTW. You can use subdirs and even individual files and 9pfs would then automatically resolve the appropriate fs device of the given path. So e.g. when using nested virtualization, an admin inside a lower level guest does not even need to know the exact mount points on a higher level / host. Best regards, Christian Schoenebeck
