On Fri, Jun 07, 2013 at 10:26:09AM +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> Goes with commit 5170711df79b28 Reviewed-by: Ben Myers <bpm@xxxxxxx> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
