From: Ted Ts'o <tytso@mit.edu>
To: Allison Henderson <achender@linux.vnet.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole failure
Date: Thu, 11 Aug 2011 19:44:45 -0400 [thread overview]
Message-ID: <20110811234445.GB31181@thunk.org> (raw)
In-Reply-To: <4E444A15.6000405@linux.vnet.ibm.com>
On Thu, Aug 11, 2011 at 02:31:01PM -0700, Allison Henderson wrote:
> Ah, ok then that makes sense. So maybe what I need to do is modify
> the ext4_block_zero_page routine to zero everything in the specified
> range and then clear the mapped flag for any buffer header that is
> fully zeroed. I'm not sure I'm clear about what it means to be
> detached though. What is the difference between clearing the flag
> and detaching the buffer head? Thank you for all the explaining!
Technically speaking, there is no guarantee that a page has either no
buffer heads, or all of the buffer heads that cover a page --- or that
the buffer_heads are in any particular order in the linked list.
In practice create_empty_buffers() creates them in a particular order,
and always creates *all* of them --- and I'm not sure if we have any
code paths left that don't use create_empty_buffers() --- but I'm
pretty sure there used to be cases where the buffer_heads could only
be partially present, or in an arbitrary order.
So if you look at the code which iterates over the page buffers,
you'll see they are very defensively coded --- and it's complicated.
One of these days I'd really like to simplify the code so instead of
using linked list, we use an array of structures --- and something
slimmed down from a buffer_head to have only those essential fields
that ext4 uses.
One of these days....
Anyway, clearing the all of the bh_flags as is currently done is good
enough, and actually probably easier (in case there's code which is
dependent on all of the bh's being there, and in order)
- Ted
prev parent reply other threads:[~2011-08-11 23:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-07 6:21 [PATCH 1/1 v4] ext4: fix xfstests 75, 112, 127 punch hole failure Allison Henderson
2011-08-08 2:42 ` Ted Ts'o
2011-08-08 20:54 ` Allison Henderson
2011-08-09 16:45 ` Ted Ts'o
2011-08-09 21:10 ` Allison Henderson
2011-08-11 3:17 ` Ted Ts'o
2011-08-11 21:31 ` Allison Henderson
2011-08-11 23:44 ` Ted Ts'o [this message]
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=20110811234445.GB31181@thunk.org \
--to=tytso@mit.edu \
--cc=achender@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/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.