> That does not address the actual issue that this patch is supposed to address, > which is the ability to provide a partial or full 'tree' of backup volumes for > general use. That somewhat depends on being able to walk the tree starting at > a given backup volume that is mounted specifically as a backup volume. And to > be sure that from there all mountpoints will resolve to backup volumes if: > > - the mointpoint is not explicitly RW or RO > - backup volumes exist for that mountpoint > > In that case a new mount syntax doesn't really do you any good, because this > type of usage needs to be able to depend on 'normal' mountpoints being processed > in a specific way.
I was thinking something along the lines of "if you traversed through a force-BK mountpt, always go BK until you hit a volume without a BK volume. The idea would be that you could make a single force-bk mount point of root.cell. Not sure it's even possible to do as I described though, since you probably only have the context of the current volume the mount is being stat'd from. An approach might be to dynamically flag the volume entry when you traverse into it as 'force-bk' depending on how you got into it, and then check that flag when expanding mount points within that volume. I just hate to dramatically change the semantics of mounts like you describe by default since it makes it impossible to use a backup volume in a way that it had previously been used. The idea does seem very useful though. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 UMR Information Technology Fax: (573) 341-4216 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
