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: Fri, 20 Jan 2006 13:24:02 -0800
Message-ID: <20060120132402.51ee5151.akpm@osdl.org>
References: <20060111174302.GD16728@atrey.karlin.mff.cuni.cz>
	<20060112142656.GB14235@atrey.karlin.mff.cuni.cz>
	<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>
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]:652 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S932216AbWATVYa (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 20 Jan 2006 16:24:30 -0500
To: Jan Kara <jack@suse.cz>
In-Reply-To: <20060120134118.GK668@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:
>
> > Jan Kara <jack@suse.cz> wrote:
> > >
> > > > (If you're proposing that we walk the buffer_head list until we somehow
> > >  > find the list_head or hlist_head which is embedded within the desired
> > >  > address_space then yes2, but how do we know where to terminate the search?)
> > >    Yes, that's it. If the list is not circular, then it's easy to find
> > >  it's head. So what I suggest is to change private_list from a circular
> > >  list of list_head structures to the non-circular one. And because
> > >  non-circular list is already implemented in hlist macros I'd simply use
> > >  those. The only minor hack is that mapping would not contain hlist_head
> > >  but hlist_node with pprev set to NULL so that we easily recognize it when
> > >  traversing backwards. Is it clearer now?
> > 
> > Ah, yes.  It could get pretty inefficient in some corner cases, I guess.  A
> > 4GB file will have up to 1000 buffers on that list so we're looking at
> > potentially O(1000000) operations.
> > 
> > Plan B is to stick with a doubly-linked list, but mark the address_space's
> > list_head by setting bit 0 of its list_head.next to 1.
> > 
> > The challenge is to implement this in a manner which Linus doesn't notice ;)
>   In the mean time I though of an improvement of our cunning plan ;) We
> could reserve a bit in bh_state. Something like BH_Neighbor_EIO. If
> buffer is going to be thrown out from private_list (and has BH_Write_EIO
> or BH_Neighbor_EIO set) we find another victim (previous buffer on the
> list) and mark it by BH_Neighbor_EIO. If the buffer was the first one,
> we can set error on the mapping. By this we get rid of going through the
> long link list.
>   I guess I like this solution enough so that I start coding ;).

hm.

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".