[PATCH 04/11] xfs: remote attribute tail zeroing does too much
Dave Chinner
david at fromorbit.com
Tue May 21 17:55:16 CDT 2013
On Tue, May 21, 2013 at 05:31:09PM -0500, Ben Myers wrote:
> On Tue, May 21, 2013 at 06:02:03PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner at redhat.com>
> >
> > When an attribute data does not fill then entire remote block, we
> > zero the remaining part of the buffer. This, however, needs to take
> > into account that the buffer has a header, and so the offset where
> > zeroing starts and the length of zeroing need to take this into
> > account. Otherwise we end up with zeros over the end of the
> > attribute value when CRCs are enabled.
> >
> > While there, make sure we only ask to map an extent that covers the
> > remaining range of the attribute, rather than asking every time for
> > the full length of remote data. If the remote attribute blocks are
> > contiguous with other parts of the attribute tree, it will map those
> > blocks as well and we can potentially zero them incorrectly. We can
> > also get buffer size mistmatches when trying to read or remove the
> > remote attribute, and this can lead to not finding the correct
> > buffer when looking it up in cache.
> >
> > Signed-off-by: Dave Chinner <dchinner at redhat.com>
>
> You fixed the bug I mentioned in the last review. Beaten.
>
> This looks ok. From the looks of things we might consider cleanup of who is
> setting rmtblkcnt in the future. It is getting to be confusing.
Yes, it is. This exact problem is one of the things my rework of the
attr CRC code later in the series fixes.
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
More information about the xfs
mailing list