From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Fix ext2 error reporting on fsync
Date: Sun, 22 Jan 2006 16:06:20 -0800
Message-ID: <20060122160620.42650e07.akpm@osdl.org>
References: <20060112124717.6e242802.akpm@osdl.org>
	<200601122108.55103.mason@suse.com>
	<20060112181628.63c4bf39.akpm@osdl.org>
	<20060118224652.GA6434@atrey.karlin.mff.cuni.cz>
	<20060118150646.7514ba5f.akpm@osdl.org>
	<20060119122125.GA12563@atrey.karlin.mff.cuni.cz>
	<20060119131648.68d7c6eb.akpm@osdl.org>
	<20060120134118.GK668@atrey.karlin.mff.cuni.cz>
	<20060120132402.51ee5151.akpm@osdl.org>
	<20060120133100.500718e5.akpm@osdl.org>
	<20060122225550.GB28667@atrey.karlin.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mason@suse.com, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp.osdl.org ([65.172.181.4]:52641 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S932356AbWAWAGs (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 22 Jan 2006 19:06:48 -0500
To: Jan Kara <jack@suse.cz>
In-Reply-To: <20060122225550.GB28667@atrey.karlin.mff.cuni.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Jan Kara <jack@suse.cz> wrote:
>
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > >  Another approach would be to allocate a new buffer_head which "belongs" to
> > >  the address_space.  So instead of doing:
> > > 
> > >  		bh<->bh<->address_space<->bh<->bh
> > > 
> > >  we do:
> > > 
> > >                       address_space
> > >                             ^
> > >                             |
> > >                             v
> > >  		bh<->bh<->bh'<->bh<->bh
> > > 
> > >  and set a magic bit in bh' which says "this is not a real bh; your
> > >  address_space is at *b_private".
> > 
> > And if we do that, we can actually shrink the address_space by 2*sizeof(long):
> > 
> > - private_list can become `struct buffer_head *metadata_buffers'
>   Ack.
> 
> > - and if we're going to abandon the address_space.private* genericity, we
> >   can remove address_space.assoc_mapping and use a new
> >   address_space->metadata_buffers->b_bdev->metadata_lock.
>   Umm, I'm not sure about this locking change. As I see the code,
> private_lock is used for serializing several players accessing the
> mapping (__find_get_block_slow, try_to_free_buffers, fsync_buffers_list,
> mark_buffer_dirty_inode, __set_page_dirty_buffers,
> invalidate_inode_buffer, remove_inode_buffers, grow_dev_page,
> create_empty_buffers, bforget). So I'm now a bit lost which of the
> private_locks belong to the mapping of the block device and which to the
> mappings of the inodes. Or should all those use device's mapping's
> private_lock and you indend to convert all those users to metadata_lock?
> 

Each inode has a list of buffer_heads at its private_list.  It so happens
that all of these buffers are against the blockdev mapping.  Hence we
always use the blockdev mapping's private_lock to protect each inode's
private_list.

Each inode records, in ->assoc_mapping, which address_space really owns the
buffers which that inode has on its private_list.  It so happens that in
all cases, inode->assoc_mapping points at the inode's backing blockdev's
address_space.

I did it this way during the lock contention reduction work so that
non-block-backed address_spaces could use the storage at private_list,
private_lock and assoc_mapping for something else.  But I don't think
anyone did that.