Cleancache: overview
in [Kernel]
|
Prev: [BUGFIX] kvm, Fix a race condition for usage of is_hwpoison_address
Next: [PATCH v2.1 1/4] netfilter: xt_ipvs (netfilter matcher for IPVS)
From: Andreas Dilger on 3 Aug 2010 14:40 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. > - 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. Cheers, Andreas -- Andreas Dilger Lustre Technical Lead Oracle Corporation Canada Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on 3 Aug 2010 15:20
> 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |