On Sat, 2025-02-15 at 11:13 +0800, Li Lingfeng wrote: > > Hi > As shown below, the server has exported three directories, with > /mnt/sdb > being a mount point. The client has mounted two directories, > test_dir1 and > test_dir2. We observed that when mounting test_dir2, it shares the > superblock of test_dir1. > > mkfs.ext4 -F /dev/sdb > mount /dev/sdb /mnt/sdb > mkdir /mnt/sdb/test_dir1 > mkdir /mnt/sdb/test_dir2 > echo "/mnt/sdb *(rw,no_root_squash)" > /etc/exports > echo "/mnt/sdb/test_dir1 *(rw,no_root_squash)" >> /etc/exports > echo "/mnt/sdb/test_dir2 *(rw,no_root_squash)" >> /etc/exports > systemctl restart nfs-server > mount -t nfs -o rw 127.0.0.1:/mnt/sdb/test_dir1 /mnt/test_mp1 > mount -t nfs -o ro 127.0.0.1:/mnt/sdb/test_dir2 /mnt/test_mp2 > > According to the description of "sharecache / nosharecache", > superblock > should be shared when mounting the same export: > > sharecache / nosharecache > Determines how the client's data cache and attribute > cache are shared when mounting the > same export more than once concurrently. Using the > same cache reduces memory require‐ > ments on the client and presents identical file > contents to applications when the same > remote file is accessed via different mount points. > > If neither option is specified, or if the sharecache > option is specified, then a single > cache is used for all mount points that access the > same export. If the nosharecache op‐ > tion is specified, then that mount point gets a > unique cache. Note that when data and > attribute caches are shared, the mount options from > the first mount point take effect for > subsequent concurrent mounts of the same export. > > As of kernel 2.6.18, the behavior specified by > nosharecache is legacy caching behavior. > This is considered a data risk since multiple cached > copies of the same file on the same > client can become out of sync following a local update > of one of the copies. > > In this scenario, is it normal for test_dir1 and test_dir2 to share > the same superblock? > That's the whole point, yes. If you want to share both the namespaces and inodes in order to deal with things like hard links, or mounts of subtrees or parents, then you have to share the same super block. NFSv4 would be a real bear to deal with for applications if the NFS client didn't know how to share byte range locks, delegations and/or pNFS layouts in these situations. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
