linux-kernel - RE: [PATCH V3 0/8] Cleancache: overview

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] [day] [month] [year] [list]

Message-ID: <af8b0006-0eb7-468a-bbf8-36ecec9bec35@default>
Date:	Tue, 3 Aug 2010 12:09:54 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Andreas Dilger <andreas.dilger@...cle.com>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	Christoph Hellwig <hch@...radead.org>, ngupta@...are.org,
	akpm@...ux-foundation.org, Chris Mason <chris.mason@...cle.com>,
	viro@...iv.linux.org.uk, adilger@....COM, tytso@....edu,
	mfasheh@...e.com, Joel Becker <joel.becker@...cle.com>,
	matthew@....cx, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, ocfs2-devel@....oracle.com,
	linux-mm@...ck.org, jeremy@...p.org, JBeulich@...ell.com,
	Kurt Hackel <kurt.hackel@...cle.com>, npiggin@...e.de,
	Dave Mccracken <dave.mccracken@...cle.com>, riel@...hat.com,
	avi@...hat.com, Konrad Wilk <konrad.wilk@...cle.com>
Subject: RE: [PATCH V3 0/8] Cleancache: overview

> From: Andreas Dilger
> Sent: Tuesday, August 03, 2010 12:34 PM
> To: Dan Magenheimer
> Subject: Re: [PATCH V3 0/8] Cleancache: overview
> 
> On 2010-08-03, at 11:35, Dan Magenheimer wrote:
> > - The FS should be block-device-based (e.g. a ram-based FS
> >  such as tmpfs should not enable cleancache)
> 
> When you say "block device based", does this exclude network
> filesystems?  It would seem cleancache, like fscache, is actually best
> suited to high-latency network filesystems.

I don't think it should exclude network FSs and agree cleancache
might be well-suited for them.  So if "block device based"
leaves out the possibility of network FSs, I am just
displaying my general ignorance of FSs and I/O, and
welcome clarification from FS developers.  What I really
meant is: Don't use cleancache for RAM-based filesystems.

> > - To ensure coherency/correctness, inode numbers must be unique
> >  (e.g. no emulating 64-bit inode space on 32-bit inode numbers)
> 
> Does it need to be restricted to inode numbers at all (i.e. can it use
> an opaque internal identifier like the NFS file handle)?  Disallowing
> cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32-
> bit system reduces its usefulness.

True... Earlier versions of the patch did not use ino_t but
instead used an opaque always-64-bit-unsigned "object id".
The patch changed to use ino_t in response to Al Viro's comment
to "use sane types".

The <pool_id,object_id,pg_offset> triple must uniquely
and permanently (unless explicitly flushed) describe
exactly one page of FS data.  So if usefulness is increased
by changing object_id back to an explicit 64-bit value,
I'm happy to do that.  The only disadvantage I can
see is that 32-bit systems pass an extra 32 bits on
every call that may always be zero on most FSs.

Thanks,
Dan
--
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/