This mail message follows from several discussions with Luke Leighton. It's mostly technical in nature but I'm submitting to all mailing lists anyway (Luke's suggestion). We have our Samba server running with the Berkeley AMD automounter (nothing peculiar here). In order for our Samba users to walk the automount tree, we created a program to create symbolic links from the local filesystem to the automounter keys. So, we have a tree that looks like the following: /amdlinks d418 (tree created from amd.d418 map) PS2MIF -> /d418/PS2MIF adm -> /d418/adm bin -> /d418/bin da abt (tree created from amd.da.abt map) dist nosw -> /da/abt/dist/nosw sw -> /da/abt/dist/sw adm (tree created from amd.da.adm map) dist sys -> /da/adm/dist/sys So, the user, using the File Manager/Explorer in windows, can map to \\samba\da or \\samba\d418 and walk the /amdlinks/da or /amdlinks/d418 tree and see all the directories that the automounter *might* mount (if we didn't do it this way, \\samba\da would map to the automounter /da directory which might not contain anything and this would make it impossible for them to "point-and-click" their way down the directory tree). The problem occurs when users descend into a directory with a list of symbolic links (such as \\samba\d418 above). When you descend into this directory, the Samba server will kick off the automounter in this directory and mount everything in /d418. This becomes a big problem when there are *many* symbolic links in a directory pointing to autmounted paths (which would then cause lots of NFS mount). So, what I would like is a "just in time links" option that returns the symbolic link to the File Manager and, not until the user "double clicks" on an entry that is a symbolic link, have it followed (and thus kick off the automounter on an "as-needed" basis). Mucking with 'follow symlinks' doesn't help at all. Setting this to 'no' still causes the flood of mounts described above. The reason for this is that only when you "double click" on the file which is a link is an lstat() call made. However, when you access \\samba\d418 above, stat() calls are done on the links which cause the mount. What I need is a simple addition where 'follow symlinks = yes' but a symbolic link is *ONLY* followed when a user "double clicks" on the file from the file manager (dunno how else to describe this). So, lstat() on one hand and stat() on the other. We are prepared to pay for this change but I need to know if it's possible. Also, the Samba server is running 1.9.18p7 on a Solaris 2.5.1 box. -- albert chin (china@pprd.abbott.com)
Luke Kenneth Casson Leighton
1998-Jun-04 14:19 UTC
Just-in-time mounts when following symlinks
[cross-posted to samba-technical, samba-ntdom and samba]. On Thu, 4 Jun 1998, Albert Chin-A-Young wrote:> This mail message follows from several discussions with Luke Leighton. > It's mostly technical in nature but I'm submitting to all mailing > lists anyway (Luke's suggestion). > > We have our Samba server running with the Berkeley AMD automounter > (nothing peculiar here). In order for our Samba users to walk the > automount tree, we created a program to create symbolic links from > the local filesystem to the automounter keys. So, we have a tree > that looks like the following: > > /amdlinks > d418 (tree created from amd.d418 map) > PS2MIF -> /d418/PS2MIF > adm -> /d418/adm > bin -> /d418/bin > da > abt (tree created from amd.da.abt map) > dist > nosw -> /da/abt/dist/nosw > sw -> /da/abt/dist/sw > adm (tree created from amd.da.adm map) > dist > sys -> /da/adm/dist/sys > > So, the user, using the File Manager/Explorer in windows, can > map to \\samba\da or \\samba\d418 and walk the /amdlinks/da or > /amdlinks/d418 tree and see all the directories that the automounter > *might* mount (if we didn't do it this way, \\samba\da would map > to the automounter /da directory which might not contain anything > and this would make it impossible for them to "point-and-click" > their way down the directory tree). > > The problem occurs when users descend into a directory with a list > of symbolic links (such as \\samba\d418 above). When you descend > into this directory, the Samba server will kick off the automounter > in this directory and mount everything in /d418. This becomes a big > problem when there are *many* symbolic links in a directory pointing > to autmounted paths (which would then cause lots of NFS mount). So, > what I would like is a "just in time links" option that returns the > symbolic link to the File Manager and, not until the user "double > clicks" on an entry that is a symbolic link, have it followed > (and thus kick off the automounter on an "as-needed" basis).my suggestion to solve this was to have a function that either calls lstat or stat with a boolean switch. then, identify _all_ SMB calls that make a stat or lstat calls. then, subdivide them into calls that need to have the real file/directory time/date and those that could get away with the file/directory link time/date. this _may_ require an smb.conf file list option. at a first guess, you could do lstat on directories, and stat on files. my second guess is simply that stat is being accidentally called (which triggers the automount lookup) in places where lstat should only be called (under the control of lp_symlinks() whatever). opinions / comments welcomed. luke
Albert Chin-A-Young wrote:> The problem occurs when users descend into a directory with a list > of symbolic links (such as \\samba\d418 above). When you descend > into this directory, the Samba server will kick off the automounter > in this directory and mount everything in /d418. This becomes a big > problem when there are *many* symbolic links in a directory pointing > to autmounted pathsBefore I open my big mouth, could someone on the list who's familiar with the algorithms used to avoid similar large-directory performance problems post a capsule description of what's being done now? I recollect discussion and patches here for MS clients stating and possibly reading material from large directories, causing somewhat pessimal behaviour (;-)) Could someone enlighten us as to what the current optimizations are what the Microsoft client requires so that we might debate the what as well as the how? --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | davecb@hobbes.ss.org, canada.sun.com M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb