> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
