David Howells <dhowells@xxxxxxxxxx> writes:
> Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote:
>
>> Consider the following example where a tcon is reused from different
>> CIFS superblocks:
>>
>> mount.cifs //srv/share /mnt/1 -o ${opts} # new super, new tcon
>> mount.cifs //srv/share/dir /mnt/2 -o ${opts} # new super, reused tcon
>>
>> So, /mnt/1/dir/foo and /mnt/2/foo will lead to different inodes.
>>
>> The two mounts are accessing the same tcon (\\srv\share) but the new
>> superblock was created because the prefix path "\dir" didn't match in
>> cifs_match_super(). Trust me, that's a very common scenario.
>
> Why does it need to lead to a different superblock, assuming ${opts} is the
> same in both cases? Can we not do as NFS does and share the superblock,
> walking during the mount process through the directory prefix to the root
> object?
I don't know why it was designed that way, but the reason we have two
different superblocks with ${opts} being the same is because cifs.ko
relies on the value of cifs_sb_info::prepath to build paths out of
dentries. See build_path_from_dentry(). So, when you access
/mnt/2/foo, cifs.ko will build a path like '[optional tree name prefix]
+ cifs_sb_info::prepath + \foo' and then reuse connections
(server+session+tcon) from first superblock to perform I/O on that file.
> In other words, why does:
>
> mount.cifs //srv/share /mnt/1 -o ${opts}
> mount.cifs //srv/share/dir /mnt/2 -o ${opts}
>
> give you a different result to:
>
> mount.cifs //srv/share /mnt/1 -o ${opts}
> mount --bind /mnt/1/dir /mnt/2
Honestly, I don't know how bind works at VFS level. I see that the new
superblock isn't created and when I access /mnt/2/foo,
build_path_from_dentry() correctly returns '\dir\foo'.
