On 1/19/2017 9:48 AM, David Howells wrote: > 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. that is a fine representation. >> 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? yes, and it is theoretically possible for its target to be modified. If that happens, the data version of the object will change. >> 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. correct, and this does cause a variety of problems. there is no method of reporting the size of the volume or the amount of free space in a volume. this is a side effect of /afs being exposed to the VFS as a single device that includes all AFS3 storage everywhere in the world. > > 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. A volume by definition is a rooted directory tree where the volume root directory vnode id is 1 and the root directory has no parent. >> 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 and I spoke offline. Create and Unlink are operations on the directory and should remain so. Read is an operation best performed on the mount point itself. Jeffrey Altman
begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United States email;internet:jaltman@xxxxxxxxxxxx title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=0D=0A= Skype: jeffrey.e.altman=0D=0A= url:https://www.auristor.com/ version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
