> > Allowing this and other flags to NOT be propagated just makes it > > possible to have a set of shared mounts with asymmetric properties, > > which may actually be desirable. > > The shared mount feature was designed to ensure that the mount remained > identical at all the locations. OK, so remount not propagating mount flags is a bug then? > Now designing features to make it un-identical but still naming it > shared, will break its original purpose. Slave mounts were designed > to make it asymmetric. What if I want to modify flags in a master mount, but not the slave mount? Would I be screwed? For example: mount is read-only in both master and slave. I want to mark it read-write in master but not in slave. What do I do? > Whatever feature that is desired to be exploited; can that be exploited > with the current set of semantics that we have? Is there a real need to > make the mounts asymmetric but at the same time name them as shared? > Maybe I dont understand what the desired application is? I do think this question of propagating mount flags is totally independent of user mounts. As it stands, currently remount doesn't propagate mount flags, and I don't see any compelling reasons why it should. The patchset introduces a new mount flag "allowusermnt", but I don't see any compelling reason to propagate this flag _either_. Please say so if you do have such a reason. As I've explained, having this flag set differently in parts of a propagation tree does not interfere with or break propagation in any way. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
