RE: [PATCH V3 0/8] Cleancache: overview
From: Dan Magenheimer
Date: Tue Aug 03 2010 - 15:12:17 EST
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/