Jeffrey Altman <jaltman@xxxxxxxxxxxx> wrote: > > I could do this by saying that you have to open the parent directory of > > the mountpoint and do an ioctl() on it, but would it be better to have one > > or more syscalls for this purpose? > > I am uncomfortable with opening the parent directory object because it > introduces object reference confusion when the path to the parent > directory is itself a symlink or a mount point. > > Granted, the AFS3 protocol does not make this easy. > > 1. An AFS3 mount point is a special type of symlink Whilst this is true in the protocol, kAFS maps that into a directory that has a ->d_automount() op. > 2. AFS3 does not provide a method by which a symlink's target can be > altered or its type changed after it is created. Can the mountpoint object be renamed and/or moved between directories? > 3. Legacy AFS3 clients have always exposed mount points to applications > as a directory not a symlink. It should be noted here that legacy AFS3 clients have a single superblock that covers all the volumes on all the cells that they mount, so mountpoints aren't actually visible to the VFS. In contrast, with kAFS, each volume is kept as a separate superblock and that is mounted directly on the mountpoint. A further note: I believe that a volume must have a directory at the base and cannot have a mountpoint there - so you shouldn't get stacked mountpoints without interference by the local sysadmin manually issuing mount commands. > If I had my preference, I would implement creating a mount point as: > > 1. create an empty file or symlink > > 2. open the resulting object and issue an ioctl against that object > to set a mount point target which results in it becoming a mount > point. Opening the mountpoint object, if it's a dangling symlink, could be tricky. There's an O_PATH that you can open with, but I'm not sure that's of use; further, if the automountpoint is actually mounted over, you can't get to the mountpoint without stepping over it. Even O_NOFOLLOW and AT_NO_AUTOMOUNT don't help. David -- 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
