> From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Subject: Re: [PATCH V3 0/8] Cleancache: overview > > On Fri, Jul 23, 2010 at 06:58:03AM -0700, Dan Magenheimer wrote: > > CHRISTOPH AND ANDREW, if you disagree and your concerns have > > not been resolved, please speak up. Hi Christoph -- Thanks very much for the quick (instantaneous?) reply! > Anything that need modification of a normal non-shared fs is utterly > broken and you'll get a clear NAK, so the propsal before is a good > one. Unless/until all filesystems are 100% built on top of VFS, I have to disagree. Abstractions (e.g. VFS) are never perfect. And the relevant filesystem maintainers have acked, so I'm wondering who you are NAK'ing for? Nitin's proposal attempts to move the VFS hooks around to fix usage for one fs (btrfs) that, for whatever reason, has chosen to not layer itself completely on top of VFS; this sounds to me like a recipe for disaster. I think Minchan's reply quickly pointed out one issue... what other filesystems that haven't been changed might encounter a rare data corruption issue because cleancache is transparently enabled for its page cache pages? It also drops requires support to be dropped entirely for another fs (ocfs2) which one user (zcache) can't use, but the other (tmem) makes very good use of. No, the per-fs opt-in is very sensible; and its design is very minimal. Could you please explain your objection further? > There's a couple more issues like the still weird prototypes, > e.g. and i_ino might not be enoug to uniquely identify an inode > on serveral filesystems that use 64-bit inode inode numbers on 32-bit > systems. This reinforces my per-fs opt-in point. Such filesystems should not enable cleancache (or enable them only on the appropriate systems). > Also making the ops vector global is just a bad idea. > There is nothing making this sort of caching inherently global. I'm not sure I understand your point, but two very different users of cleancache have been provided, and more will be discussed at the MM summit next month. Do you have a suggestion on how to avoid a global ops vector while still serving the needs of both existing users? 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
