linux-kernel - Re: Question about sharecache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <793e66cb7551ccf1d94c64aa886446d858fc678d.camel@hammerspace.com>
Date: Sat, 15 Feb 2025 03:35:59 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "anna@...nel.org" <anna@...nel.org>, "lilingfeng3@...wei.com"
	<lilingfeng3@...wei.com>
CC: "houtao1@...wei.com" <houtao1@...wei.com>, "linux-nfs@...r.kernel.org"
	<linux-nfs@...r.kernel.org>, "yukuai3@...wei.com" <yukuai3@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"yangerkun@...wei.com" <yangerkun@...wei.com>, "yi.zhang@...wei.com"
	<yi.zhang@...wei.com>
Subject: Re: Question about sharecache

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@...merspace.com