From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: sfr@canb.auug.org.au, nfsv4@linux-nfs.org, steved@redhat.com,
linux-kernel@vger.kernel.org, dhowells@redhat.com,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
rwheeler@redhat.com
Subject: Re: Pull request for FS-Cache, including NFS patches
Date: Fri, 19 Dec 2008 13:32:24 +0000 [thread overview]
Message-ID: <10970.1229693544@redhat.com> (raw)
In-Reply-To: <1229690036.7789.113.camel@heimdal.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> One interesting use case that I didn't see David mention is for cluster
> boot up. In a lot of the HPC clustered set-ups there tend be a number of
> 'hot' files that all clients need to access at roughly the same time in
> the boot cycle. Pre-loading these files into the persistent cache before
> booting the cluster is one way to solve this problem. Server replication
> and/or copying the files to local storage on the clients are other
> solutions.
I've come across something similar, where a large company was distributing /usr
to its UNIX/Linux workstations by AFS without persistent local caching. Cue a
powercut, that took away the power from a large quantity of machines and then
brought it back again, at which point all the machines tried to boot...
> The disadvantage is that cachefs doesn't yet appear to have a tool to select
> those files that are hot and are therefore best suited to cache (please
> correct me if I'm wrong, David). The fact that a file is 'hot' on some given
> client is not necessarily equivalent to saying that it is hot on the server
> and vice versa. Are there any plans to at some point introduce a tool to
> manage the persistent cache?
Yes. I have plans for tools to pin and unpin files, introduce culling
priorities, make space reservations in the cache, and cache readahead.
These aren't, however, immediately necessary to make local caching useful.
To do this, ideally I want a set of ioctl, fcntl or fadvise commands that are
common to all filesystems that will just be ignored if the filesystem isn't
currently doing caching.
Our customers also want to be able to configure this statically, perhaps in
some /etc file. Something like, on NFS mount X from server Y, fully readahead
all files in or under directory Z. I have an idea on how to do this, but I
need to thrash it out with Al.
David
next prev parent reply other threads:[~2008-12-19 13:32 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
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 [this message]
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=10970.1229693544@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=rwheeler@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=steved@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;
as well as URLs for NNTP newsgroup(s).