From: David Howells <dhowells@redhat.com>
To: Jon Masters <jonathan@jonmasters.org>
Cc: dhowells@redhat.com, Peter Staubach <staubach@redhat.com>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
Steve Dickson <SteveD@redhat.com>,
nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org
Subject: Re: How to manage shared persistent local caching (FS-Cache) with NFS?
Date: Wed, 05 Dec 2007 18:03:58 +0000 [thread overview]
Message-ID: <6513.1196877838@redhat.com> (raw)
In-Reply-To: <1196876999.3325.5.camel@jcmlaptop>
Jon Masters <jonathan@jonmasters.org> wrote:
> I think the shared superblock approach is the right one, but I'm a
> little concerned that there would now be different behavior for fscache
> and non-cached setups. Not sure of any better idea though.
The behaviour varies a bit anyway because there's a cache...
> > The R/O mount flag can be dealt with by moving readonlyness into the
> > vfsmount rather than having it a property of the superblock. The
> > superblock would then be read-only only if all its vfsmounts are also
> > read-only.
>
> Given that, how many connection parameters are there that are likely to
> actually differ on the same client, talking to the same server? Really?
I don't have figures on that, but I do know people have complained about it
for non-cached conditions.
> You could store the table in a NIS map, for example, and a udev rule or
> similar could trigger to load it later.
My point was meant to be that the presence and coverage of a cache is more
likely to reflect the client machine than would the NIS map for the NFS
automounts. You wouldn't necessarily want to store this table in NIS.
David
next prev parent reply other threads:[~2007-12-05 18:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-05 17:11 How to manage shared persistent local caching (FS-Cache) with NFS? David Howells
2007-12-05 17:49 ` Jon Masters
2007-12-05 18:03 ` David Howells [this message]
2007-12-05 19:54 ` Chuck Lever
2007-12-06 1:22 ` David Howells
2007-12-06 18:28 ` Chuck Lever
2007-12-06 20:00 ` David Howells
2007-12-07 17:59 ` Chuck Lever
2007-12-08 0:52 ` David Howells
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=6513.1196877838@redhat.com \
--to=dhowells@redhat.com \
--cc=SteveD@redhat.com \
--cc=jonathan@jonmasters.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=staubach@redhat.com \
--cc=trond.myklebust@fys.uio.no \
/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