Messages in this thread | | | Date | Wed, 17 Apr 2024 14:59:50 -0400 | Subject | Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live connection | From | Tom Talpey <> |
| |
On 4/17/2024 10:38 AM, David Howells wrote: > Paulo Alcantara <pc@manguebit.com> 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
The tcon is a property of the SMB3 session, it's not shared nor is it necessarily created at mount time.
Tom.
> 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? > > 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 > > David > > >
| |