Re: [PATCH] Fix ext2 error reporting on fsync

[Jan Kara <jack@suse.cz>]

> Jan Kara <jack@suse.cz> wrote:
> >
> > > It's not much complexity: a few set_bits and test_and_clear_bits in three
> >  > places.  The main drawback is a larger buffer_head.
> >  > 
> >  > Yeah, it's a pita, but it is a data-integrity correctness thing.
> >    There's a way to avoid the extra pointer in buffer_head: we could
> >  change the circular linked list b_assoc_buffers to a non-circular one
> >  (probably use hlists). Then if we find a buffer with IO error, we could
> >  find a list head and from it compute the pointer to the mapping... It
> >  would not be fast but on IO error I think we could afford it. Do you think
> >  it's a good idea?
> 
> I don't understand.  We have a pointer to a buffer_head against the
> blockdev mapping and we want to find, from that, the S_ISREG address_space
> which has connected that buffer to itself.  Precisely how are you proposing
> that we do that?
  OK, my explanation was probably too brief. So once more :)

> (If you're saying that the hlist space saving would allow us to add an
> address_space* pointer to the bh at no space cost then yes).
  list_head has the same size as hlist_head so I don't think we'll save
any space. Anyway I meant what you write below.

> (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?

								Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs