mount MS DFS

[Steven French]

>% mount.cifs //123.123.123.123/DFSRoot /mnt/DFS -o user=name,pass=*** 
>mount error 20 = Not a directoryRefer to the mount.cifs(8) manual page 
>(e.g.man mount.cifs) 
> 
>mount -t smbfs -o username=name,password=*** 
>//winserver/DFSRoot/mnt/DFS 
>works, but in the DFS directory (cd /mnt/DFS) I see folders which are 
>empty. 
> 
>What I'm doing wrong? 

In the smbfs case since the client does not advertise ms dfs support the 
server reports the dfs junctions as directories (which it can not access 
therefore appear empty).  In the cifs vfs case (since it does advertise 
dfs support) the directories are seen internally by the client as what 
they really are (dfs junctions / reparse points for the case of Windows 
servers, and in the case of Samba servers with the Unix extensions enabled 
they are seen as a broken form of symlink).    Although the cifs vfs, 
unlike smbfs, can lookup the dfs referrals, the cifs vfs can not complete 
the mounting to the target server (yet) since the client lacks the 
ultimate target server's ip address (the mount helper is missing a helper 
thread to do DNS hostname lookups).    I will take a look at whether the 
referrals to UNC names of the less common form \\ip_address\share (rather 
than \\tcp_nameshare) can be mounted with minor change to the client.

The code for the upcall to the helper thread needs to be written but is 
not likely to be a substantial change.    Part of the delay has been 
hoping/waiting for someone (perhaps the NFSv4 guys) to write a more 
elegant new Linux upcall mechanism (there are multiple mechanisms used for 
kernel to user space communication today).

Currently I am focused on an unrelated bug in reopen_files in 
fs/cifs/file.c in which the locking logic is incorrect and the open file 
list is getting corrupted.   This bug is getting in the way of figuring 
out why Samba 3 is taking more than 45 seconds to respond to requests 
under large single client, multiple process stress.   When the number of 
simultaneous requests from a client goes over 25 or so I am seeing very 
long delays on the server (even on the common QueryPathInfo unix info) 
which are causing tcp session crashes and unfortunately exercising the 
client reconnection code and turning up a few bugs.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com