mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "anna@kernel.org" <anna@kernel.org>,
	"lilingfeng3@huawei.com" <lilingfeng3@huawei.com>
Cc: "houtao1@huawei.com" <houtao1@huawei.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"yukuai3@huawei.com" <yukuai3@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yangerkun@huawei.com" <yangerkun@huawei.com>,
	"yi.zhang@huawei.com" <yi.zhang@huawei.com>
Subject: Re: Question about sharecache
Date: Sat, 15 Feb 2025 03:35:59 +0000	[thread overview]
Message-ID: <793e66cb7551ccf1d94c64aa886446d858fc678d.camel@hammerspace.com> (raw)
In-Reply-To: <1ed195ab-2e9d-40b9-acd9-6989413b6bbf@huawei.com>

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



           reply	other threads:[~2025-02-15  3:36 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1ed195ab-2e9d-40b9-acd9-6989413b6bbf@huawei.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=793e66cb7551ccf1d94c64aa886446d858fc678d.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=anna@kernel.org \
    --cc=houtao1@huawei.com \
    --cc=lilingfeng3@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®