[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Pull request for FS-Cache, including NFS patches
    On Thu, 2008-12-18 at 18:44 -0800, Andrew Morton wrote:
    > On Fri, 19 Dec 2008 02:27:24 +0000 David Howells <> wrote:
    > > > Are any distros pushing for this? Or shipping it? If so, are they
    > > > able to weigh in and help us with this quite difficult decision?
    > >
    > > We (Red Hat) have shipped it in RHEL-5 and some Fedora releases. Doing so is
    > > quite an effort, though, precisely because the code is not yet upstream. We
    > > have customers using it and are gaining more customers who want it. There
    > > even appear to be CentOS users using it (or at least complaining when it
    > > breaks).
    > That's useful news.
    > >
    > > I don't know what will convince you. I've given you theoretical reasons why
    > > caching ought to be useful; I've backed up the ones I've implemented with
    > > benchmarks; I've given you examples of what our customers are doing with it or
    > > want to do with it.
    > Was that information captured/maintained somewhere? It really is important (I
    > think) for something of this magnitude.
    > > Please help me understand what else you want.
    > I want to be able to have an answer when someone asks me "why was all that
    > stuff merged". One which I can believe.
    > > Do you perhaps want the netfs maintainers (such as Trond) to say that it's
    > > necessary?
    > Of course, their opinions (and supporting explanations) would be valuable.

    OK. I do agree that persistent caches can be (sometimes very!) useful
    for certain workloads. As far as I'm concerned, it is mainly a tool to
    help scale up the number of clients per server.

    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
    The advantage the persistent cache confers over the two other solutions
    is that it simplifies the data management: if you do need to change one
    or two of those hot files on the server, then the clients will
    automatically update their caches (both the page cache and the
    persistent cache) without requiring any further action from the cluster
    administrator. 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?


     \ /
      Last update: 2008-12-19 13:37    [W:0.026 / U:76.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site