[Ocfs2-devel] [PATCH V3 0/8] Cleancache: overview

[Dan Magenheimer]

> 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