From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Bernd Schubert <bernd.schubert@fastmail.fm>,
nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org,
steved@redhat.com, dhowells@redhat.com,
linux-next@vger.kernel.org, linux-fsdevel@vger.kernel.org,
rwheeler@redhat.com
Subject: Re: Pull request for FS-Cache, including NFS patches
Date: Mon, 29 Dec 2008 15:01:09 +0000 [thread overview]
Message-ID: <12214.1230562869@redhat.com> (raw)
In-Reply-To: <20081228200134.426bf203.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> > What was the result of discussions around FS-Cache?
>
> There was none.
I disagree with your assertion that there was no result. Various people,
beside myself, have weighed in with situations where FS-Cache is or may be
useful. You've been presented with benchmarks showing that it can make a
difference.
However, *you* are the antagonist, as strictly defined in the dictionary; we
were trying to convince *you*, so a result has to come from *you*. I feel
that you are completely against it and that we've no hope of shifting you.
> Dan Muntz's question:
>
> Solaris has had CacheFS since ~1995, HPUX had a port of it since
> ~1997. I'd be interested in evidence of even a small fraction of
> Solaris and/or HPUX shops using CacheFS. I am aware of customers who
> thought it sounded like a good idea, but ended up ditching it for
> various reasons (e.g., CacheFS just adds overhead if you almost
> always hit your local mem cache).
>
> was an very very good one.
And to a large extent irrelevant. Yes, we know caching adds overhead; I've
never tried to pretend otherwise. It's an exercise in compromise. You don't
just go and slap a cache on everything. There *are* situations in which a
cache will help. We have customers who know about them and are willing to
live with the overhead.
What I have done is to ensure that, even if caching is compiled in, then the
overhead is minimal if there is _no_ cache present. That is requirement #1 on
my list.
Assuming I understand what he said correctly, I've avoided the main issue
listed by Dan because I don't do as Solaris does and interpolate the cache
between the user and NFS. Of course, that probably buys me other issues (FS
design is an exercise in compromise too).
> Seems that instead of answering it, we've decided to investigate the
> fate of those who do not learn from history.
Sigh.
The main point is that caching _is_ useful, even with its drawbacks. Dan may
be aware of customers of Sun/HP who thought caching sounds like a good idea,
but then ended up ditching it. I can well believe it. But I am also aware of
customers of Red Hat who are actively using the caching we put in RHEL-5 and
customers who really want caching available in future RHEL and Fedora versions
for various reasons.
To sum up:
(1) Overhead is minimal if there is no cache.
(2) Benchmarks show that the cache can be effective.
(3) People are already using it and finding it useful.
(4) There are people who want it for various projects.
(5) The use of a cache does not automatically buy you an improvement in
performance: it's a matter of compromise.
(6) The performance improvement may be in the network or the servers, not the
client that is actually doing the caching.
David
next prev parent reply other threads:[~2008-12-29 15:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 0:30 Pull request for FS-Cache, including NFS patches David Howells
2008-12-18 11:44 ` Stephen Rothwell
2008-12-18 14:24 ` Christoph Hellwig
2008-12-18 20:36 ` Andrew Morton
2008-12-18 23:07 ` Bernd Schubert
2008-12-18 23:26 ` Andrew Morton
2008-12-19 0:05 ` Stephen Rothwell
2008-12-29 3:45 ` Stephen Rothwell
2008-12-29 4:01 ` Andrew Morton
2008-12-29 14:30 ` Trond Myklebust
2008-12-29 14:54 ` Ric Wheeler
2008-12-29 23:05 ` Muntz, Daniel
2008-12-30 18:44 ` Trond Myklebust
2008-12-30 22:15 ` Muntz, Daniel
2008-12-30 22:36 ` Trond Myklebust
2008-12-30 23:00 ` Muntz, Daniel
2008-12-30 23:17 ` Trond Myklebust
2009-01-01 4:11 ` Muntz, Daniel
2009-01-01 8:09 ` Arjan van de Ven
2009-01-01 18:40 ` Kyle Moffett
2008-12-31 11:15 ` David Howells
2008-12-31 9:49 ` Arjan van de Ven
2008-12-29 4:07 ` Andrew Morton
2008-12-29 5:26 ` Stephen Rothwell
2008-12-29 15:01 ` David Howells [this message]
2008-12-29 15:04 ` David Howells
2008-12-29 14:26 ` David Howells
2008-12-19 2:27 ` David Howells
2008-12-19 2:44 ` Andrew Morton
2008-12-19 3:10 ` Ric Wheeler
2008-12-19 12:33 ` Trond Myklebust
2008-12-19 16:48 ` Gabor Gombas
2008-12-19 13:32 ` David Howells
2008-12-19 3:45 ` Muntz, Daniel
2008-12-19 4:09 ` J. Bruce Fields
2008-12-19 13:20 ` David Howells
2008-12-19 18:08 ` Muntz, Daniel
2008-12-19 18:24 ` David Howells
2008-12-19 19:53 ` Bryan Henderson
2008-12-20 1:20 ` David Howells
2008-12-20 6:05 ` Muntz, Daniel
2008-12-19 13:22 ` David Howells
2008-12-19 13:03 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2008-12-20 6:06 Muntz, Daniel
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=12214.1230562869@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bernd.schubert@fastmail.fm \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=rwheeler@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=steved@redhat.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;
as well as URLs for NNTP newsgroup(s).