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:

quoted

- 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.
 

quoted

- 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>