RE: [PATCH V3 0/8] Cleancache: overview
From: Dan Magenheimer <hidden>
Date: 2010-08-03 17:35:57
Also in:
linux-btrfs, linux-fsdevel, linux-mm, lkml, ocfs2-devel
From: Boaz Harrosh [mailto:bharrosh@panasas.com] Sent: Tuesday, August 03, 2010 10:23 AM To: Dan Magenheimer Subject: Re: [PATCH V3 0/8] Cleancache: overview On 07/24/2010 12:17 AM, Dan Magenheimer wrote:quoted
quoted
quoted
On Fri, Jul 23, 2010 at 06:58:03AM -0700, Dan Magenheimer wrote:quoted
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!quoted
Anything that need modification of a normal non-shared fs isutterlyquoted
quoted
quoted
broken and you'll get a clear NAK, so the propsal before is a good one.No, the per-fs opt-in is very sensible; and its design is very minimal.Not to belabor the point, but maybe the right way to think about this is: Cleancache is a new optional feature provided by the VFS layer that potentially dramatically increases page cache effectiveness for many workloads in many environments at a negligible cost. Filesystems that are well-behaved and conform to certain restrictions can utilize cleancache simply by making a call to cleancache_init_fs at mount time. Unusual, misbehaving, or poorly layered filesystems must either add additional hooks and/or undergo extensive additional testing... or should just not enable the optional cleancache.OK, So I maintain a filesystem in Kernel. How do I know if my FS is not "Unusual, misbehaving, or poorly layered"
A reasonable question. I'm not a FS expert so this may not be a complete answer, but please consider it a start: - The FS should be block-device-based (e.g. a ram-based FS such as tmpfs should not enable cleancache) - To ensure coherency/correctness, the FS must ensure that all file removal or truncation operations either go through VFS or add hooks to do the equivalent "flush" operations (e.g. I started looking at FS-cache-based net FS's and was concerned there might be problems, dunno for sure) - To ensure coherency/correctness, inode numbers must be unique (e.g. no emulating 64-bit inode space on 32-bit inode numbers) - The FS must call the VFS superblock alloc and deactivate routines or add hooks to do the equivalent cleancache calls done there. - To maximize performance, all pages fetched from the FS should go through the do_mpage_readpage routine or the FS should add hooks to do the equivalent (e.g. btrfs requires a hook for this) - Currently, the FS blocksize must be the same as PAGESIZE. This is not an architectural restriction, but no backends currently support anything different (e.g. hugetlbfs? should not enable cleancache) - A clustered FS should invoke the "shared_init_fs" cleancache hook to get best performance for some backends. Does that help? 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>