[linux-cifs-client] Re: CIFS home mount won't allow KDE to, run

[Steve French]

Paul Waldo wrote:

> Steve French wrote:
>
>> Also note that the default is not to use serverino since mount points 
>> can cross device boundaries (and thus duplicate inode numbers can be 
>> possible depending on how the server shares are configured) - when we 
>> finish merging the DFS patch we can use the same concept introduced 
>> there (ie of "shrinkable mounts" and junctions) to handle the case of 
>> a server which exports more than one device (and thus workaround 
>> duplicate inode numbers by doing "implicit mounts")
>>
>
> Hi Steve,
>
> That first part worries me.  Is this the scenario you are talking about?:
> 1. Mount CIFS share 1 on /a/b
> 2. mkdir /a/b/c
> 3. Mount CIFS share 2 on a/b/c
>
> Thanks!
>
> Paul
>
>
No - not worried about that scenario, but instead consider the following:

Server mounts /dev/hda1 on /public and /dev/hda2 on /public/engineering
Server exports /public as \\server\public-share

Without the server doing some work, there could be two inodes with the 
same inode number (if we use server inode numbers)

Fortunately for this scenario Samba constructs the 64 bit unique file 
identifiers from 32 bit device number and 32 bit inode number which is 
probably fine, but what about other types of NAS boxes with 64 bit inode 
numbers that can't or don't use the device number?  What about Windows 
servers which might export:

c:\public but c:\public\junction is a junction to d:\

Do they guarantee that that the 64 bit file identifiers under 
\\server\public-share are unique?

What I was getting at with my earlier post, was that there is a way to 
address this, as with DFS, the CIFS client could look for the device 
number and "implicitly mount" when we cross into the lower directory 
with the new device number (now that the Linux VFS has the concept of a 
"shrinkable mount" which implicitly gets unmounted when its parent is 
unmounted) - this should avoid the problem with using unique inode 
numbers when the server has exported a directory that is "above" the 
root of a device.