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. But that seems to ignore a whole class of servers, who are local NFS clients of both other servers *and* themselves.
All of my data disks are always mounted in at /export/SOMETHING on my file servers. All of the clients of those servers mount those filesystems under /import, usually /import/SOMETHING, but sometimes /import/SOME/THING/ELSE. Many times the path used to access these filesystems on the clients needs to be a valid path on the server also. So I always make sure that the /import/.... path works on the server too - which for NFS and NIS and the Automounter doesn't really take any effort at all. I'll admit that I'm not an exprt on the newest features of NFSv4, and CIFS, so it's not entirely clear to me how, or when (or IF?) I'd ever want to use these reparse points, but unless I'm missing something, I know I'd want them to work locally the same as they will on the client. -Kyle > > 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. > > Rob T > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
