On Mon, Jul 13, 2009 at 09:47:23AM -0600, Robert Thurlow wrote: > Hugh McIntyre wrote: > > >But this raises the point that if these special reparse symlinks were > >implemented such that the reparsing also happened when the filesystem is > >mounted locally via mount_zfs or mount_lofs, not just remotely over CIFS > >or NFSv4, then most of the issues would go away. > > > >In other words if open(), stat(), nftw(), and similar system calls > >locally on the server hosting the files (including LOFS) access the > >linked-to file, most code will think the link is OK. Since in this > >case, "find -L" should point to the target of the reparse point (which > >hopefully exists). > > The project team is pretty interested in semantics seen by > NFS and CIFS clients, not local semantics, so we're not > terribly excited to do work to make local access act like > that; I get the motivations, but it's a whole lot of work.
A future project could make reparse points be interpreted locally. There are two ways that that could be done: 1) Have the kernel notice that a path component is a reparse point and cause the target to be mounted. 2) Make the reparse point symlink contents start with a reserved absolute path such as, say, "/ref", so a special automounter map can be implemented later to evaluate and automount referrals. In the meantime the mountpoint for this future special map could be reserved by including an auto_master entry that mounts the -null special map (I'm not sure that -null works quite the way I think, but even if not, this entry could help document the reserved path prefix). Note too that such an automounter map could just be an executable map, possibly a simple script. If you don't ensure that reparse point contents look like an absolute path, then (2) will be precluded. That's OK since (1) remains possible, but you'd have to at least acknowledge this in making this choice. ALSO, you don't want random symlink contents to be confusable with reparse points. I think the risk of that is miniscule, but non-zero, and that concerns me more. The system attribute on reparse points, if _required_ in order for a reparse point to be treated as such, avoids that problem. It might be useful to reserve symlink contents sub-namespaces (when used with a special typing attribute, as in this case), so as to avoid confusability. Also, instead of having an extensible system attribute whose presence indicates that this is a reparse point, how about an extensible system attribute whose value indicates the real type of this object? We might need to resort to this symlink "sub-typing" scheme again in the future... IMO (1) is the better model, but the fact that (2) could be implemented as an executable map is very appealing. You should consider (2) before rejecting it. (Also, (1) could still rely on autofs infrastructure to make implementation easier.) > There are also difficulties. We know we will want to set > up a reparse point that projects the same namespace for > both NFS and CIFS, and it isn't obvious what client code > we would bridge into locally. We would also like to be > able to back up reparse points, so local processes need to > access them without interpretation. For the last part there are many ways to achieve that. Just using extended attributes is enough -- the referral could be stored in an extended attribute, and the object's type could be irrelevant. Backup tools that are aware of extended attributes would backup reparse points w/o any trouble. Using symlinks makes the reparse point somewhat more accessible to users, but it doesn't seem strictly necessary (there's always runat(1)), more like the resulf of a [likely very useful] optimization. (Also, I have to say that I agree with J?rg that overloading symlinks seems unfortunate. But because adding a new filesystem object type is hard (backup and other tools wouldn't know what to do with it), this is just unfortunate and that's that -- c'est la vie.) Nico --
