linux-fsdevel.vger.kernel.org archive mirror
 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: Wed, 18 Jan 2006 15:06:46 -0800	[thread overview]
Message-ID: <20060118150646.7514ba5f.akpm@osdl.org> (raw)
In-Reply-To: <20060118224652.GA6434@atrey.karlin.mff.cuni.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?

(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).

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

  reply	other threads:[~2006-01-18 23:07 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 [this message]
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
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=20060118150646.7514ba5f.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).