linux-kernel - Re: Pull request for FS-Cache, including NFS patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200812190007.34581.bernd.schubert@fastmail.fm>
Date:	Fri, 19 Dec 2008 00:07:33 +0100
From:	Bernd Schubert <bernd.schubert@...tmail.fm>
To:	nfsv4@...ux-nfs.org
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, steved@...hat.com,
	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	rwheeler@...hat.com
Subject: Re: Pull request for FS-Cache, including NFS patches

On Thursday 18 December 2008, Andrew Morton wrote:
> On Thu, 18 Dec 2008 09:24:20 -0500
>
> Christoph Hellwig <hch@...radead.org> wrote:
> > On Thu, Dec 18, 2008 at 10:44:18PM +1100, Stephen Rothwell wrote:
> > > Added from today.
> > >
> > > Usual spiel: all patches in that branch must have been
> > > 	posted to a relevant mailing list
> > > 	reviewed
> > > 	unit tested
> > > 	destined for the next merge window (or the current release)
> > > *before* they are included.
> >
> > I don't think we want fscache for .29 yet.  I'd rather let the
> > credential code settle for one release, and have more time for actually
> > reviewing it properly and have it 100% ready for .30.
>
> I don't believe that it has yet been convincingly demonstrated that we
> want to merge it at all.
>
> It's a huuuuuuuuge lump of new code, so it really needs to provide
> decent value.  Can we revisit this?  Yet again?  What do we get from
> all this?
>

I really don't understand why fs-cache is always rejected. Actually it is the 
perfect solution for NFS booted systems - you have a big cluster of nodes and 
in order to minimize administration overhead the nodes are booted over NFS 
from one common chroot. With unionfs (preferred solution here is unionfs-fuse) 
one then maintains files required to be differently by different clients.

Caching files on the local disk minimized the network access and boosts the 
performance, so at least for this usage example fs-cache would be great.
(Actually I have been thinking about to implement a caching branch into 
unionfs-fuse, but if the kernel can do it on its own, it is also fine.)

In the past David already posted many benchmarks and just a few weeks ago 
again:

http://lkml.indiana.edu/hypermail/linux/kernel/0811.3/00584.html

Cheers,
Bernd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/