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
parent 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®