On Tue, May 28, 2013 at 06:37:17PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
>
> When the directory freespace index grows to a second block (2017
> 4k data blocks in the directory), the initialisation of the second
> new block header goes wrong. The write verifier fires a corruption
> error indicating that the block number in the header is zero. This
> was being tripped by xfs/110.
>
> The problem is that the initialisation of the new block is done just
> fine in xfs_dir3_free_get_buf(), but the caller then users a dirv2
> structure to zero on-disk header fields that xfs_dir3_free_get_buf()
> has already zeroed. These lined up with the block number in the dir
> v3 header format.
>
> While looking at this, I noticed that the struct xfs_dir3_free_hdr()
> had 4 bytes of padding in it that wasn't defined as padding or being
> zeroed by the initialisation. Add a pad field declaration and fully
> zero the on disk and in-core headers in xfs_dir3_free_get_buf() so
> that this is never an issue in the future. Note that this doesn't
> change the on-disk layout, just makes the 32 bits of padding in the
> layout explicit.
>
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> ---
> fs/xfs/xfs_dir2_format.h | 1 +
> fs/xfs/xfs_dir2_node.c | 13 ++++++-------
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/fs/xfs/xfs_dir2_format.h b/fs/xfs/xfs_dir2_format.h
> index a3b1bd8..995f1f5 100644
> --- a/fs/xfs/xfs_dir2_format.h
> +++ b/fs/xfs/xfs_dir2_format.h
> @@ -715,6 +715,7 @@ struct xfs_dir3_free_hdr {
> __be32 firstdb; /* db of first entry */
> __be32 nvalid; /* count of valid entries */
> __be32 nused; /* count of used entries */
> + __be32 pad; /* 64 bit alignment. */
Yeah, my count also puts nused short of 64 bit alignment. Looks ok.
Reviewed-by: Ben Myers <bpm@xxxxxxx>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
