Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765536AbXJREd0 (ORCPT ); Thu, 18 Oct 2007 00:33:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752800AbXJREdD (ORCPT ); Thu, 18 Oct 2007 00:33:03 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:50618 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752584AbXJREdB (ORCPT ); Thu, 18 Oct 2007 00:33:01 -0400 Date: Wed, 17 Oct 2007 21:32:16 -0700 From: Andrew Morton To: ebiederm@xmission.com (Eric W. Biederman) Cc: Chris Mason , Christian Borntraeger , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Martin Schwidefsky , "Theodore Ts'o" , stable@kernel.org Subject: Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings. Message-Id: <20071017213216.b2d0c4bd.akpm@linux-foundation.org> In-Reply-To: References: <200710151028.34407.borntraeger@de.ibm.com> <200710160956.58061.borntraeger@de.ibm.com> <200710171814.01717.borntraeger@de.ibm.com> <1192648456.15717.7.camel@think.oraclecorp.com> <1192654481.15717.16.camel@think.oraclecorp.com> <1192661889.15717.27.camel@think.oraclecorp.com> <1192665785.15717.34.camel@think.oraclecorp.com> X-Mailer: Sylpheed 2.4.1 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2243 Lines: 44 On Wed, 17 Oct 2007 21:59:02 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote: > If filesystems care at all they want absolute control over the buffer > cache. Controlling which buffers are dirty and when. Because we > keep the buffer cache in the page cache for the block device we have > not quite been giving filesystems that control leading to really weird > bugs. > > In addition this tieing of the implemetation of block device caching > and the buffer cache has resulted in a much more complicated and > limited implementation then necessary. Block devices for example > don't need buffer_heads, and it is perfectly reasonable to cache > block devices in high memory. > > To start untangling the worst of this mess this patch introduces a > second block device inode for the buffer cache. All buffer cache > operations are diverted to that use the new bd_metadata_inode, which > keeps the weirdness of the metadata requirements isolated in their > own little world. I don't think we little angels want to tread here. There are so many weirdo things out there which will break if we bust the coherence between the fs and /dev/hda1. Online resize, online fs checkers, various local tools which people have hacked up to look at metadata in a live fs, direct-io access to the underlying fs, heaven knows how many boot loader installers, etc. Cerainly I couldn't enumerate tham all. The mere thought of all this scares the crap out of me. I don't actually see what the conceptual problem is with the existing implementation. The buffer_head is a finer-grained view onto the blockdev's pagecache: it provides additional states and additional locking against a finer-grained section of the page. It works well. Yeah, the highmem thing is a bit of a problem (but waning in importance). But we can fix that by teaching individual filesystems about kmap and then tweak the blockdev's caching policy with mapping_set_gfp_mask() at mount time. If anyone cares, which they don't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/