All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Jan Kara <jack@suse.cz>
Cc: mason@suse.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Fix ext2 error reporting on fsync
Date: Fri, 20 Jan 2006 13:24:02 -0800	[thread overview]
Message-ID: <20060120132402.51ee5151.akpm@osdl.org> (raw)
In-Reply-To: <20060120134118.GK668@atrey.karlin.mff.cuni.cz>

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

  reply	other threads:[~2006-01-20 21:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11 17:43 [PATCH] Fix ext2 error reporting on fsync Jan Kara
2006-01-12  4:24 ` Andrew Morton
2006-01-12 10:20   ` Jan Kara
2006-01-12 11:52     ` Andrew Morton
2006-01-12 13:58       ` Chris Mason
2006-01-12 14:21         ` Jan Kara
2006-01-12 15:36           ` Chris Mason
2006-01-12 16:32             ` Jan Kara
2006-01-12 14:26       ` Jan Kara
2006-01-12 20:47         ` Andrew Morton
2006-01-13  2:08           ` Chris Mason
2006-01-13  2:16             ` Andrew Morton
2006-01-18 22:46               ` Jan Kara
2006-01-18 23:06                 ` Andrew Morton
2006-01-19 12:21                   ` Jan Kara
2006-01-19 21:16                     ` Andrew Morton
2006-01-20 13:41                       ` Jan Kara
2006-01-20 21:24                         ` Andrew Morton [this message]
2006-01-20 21:31                           ` Andrew Morton
2006-01-20 21:33                             ` Andrew Morton
2006-01-22 22:55                             ` Jan Kara
2006-01-23  0:06                               ` Andrew Morton
2006-01-22 22:32                           ` Jan Kara
2006-01-22 23:31                           ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060120132402.51ee5151.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mason@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.