Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 10 Apr 2002 07:34:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 10 Apr 2002 07:34:32 -0400 Received: from leibniz.math.psu.edu ([146.186.130.2]:16098 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Wed, 10 Apr 2002 07:34:31 -0400 Date: Wed, 10 Apr 2002 07:34:30 -0400 (EDT) From: Alexander Viro To: Andrew Morton cc: lkml Subject: Re: [prepatch] address_space-based writeback In-Reply-To: <3CB4203D.C3BE7298@zip.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 Apr 2002, Andrew Morton wrote: > > This is a largish patch which makes some fairly deep changes. It's > currently at the "wow, it worked" stage. Most of it is fairly > mature code, but some conceptual changes were recently made. > Hopefully it'll be in respectable state in a few days, but I'd > like people to take a look. > > The idea is: all writeback is against address_spaces. All dirty data > has the dirty bit set against its page. So all dirty data is > accessible by > > superblock list > -> superblock dirty inode list > -> inode mapping's dirty page list. > -> page_buffers(page) (maybe) Wait. You are assuming that all address_spaces happen to be ->i_mapping of some inode. Which is less than obvious - e.g. putting indirect blocks into private per-inode address_space is not unreasonable. What's more, I wonder how well does your scheme work with ->i_mapping to a different inode's ->i_data (CODA et.al., file access to block devices). BTW, CODA-like beasts can have several local filesystems for cache - i.e. ->i_mapping for dirty inodes from the same superblock can ultimately go to different queues. Again, the same goes for stuff like dd if=foo of=/dev/floppy - you get dirty inode of /dev/floppy with ->i_mapping pointing to bdev filesystem and queue we end up with having nothing in common with that of root fs' device. I'd really like to see where are you going with all that stuff - if you expect some correspondence between superblocks and devices, you've are walking straight into major PITA. - 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/