Sorry for the delay. I've been trying to put together a simpler
reproducer since no one wants to debug a filesystem based on rbd
symptoms :). It doesn't appear to be related to using extsize on a
non-empty file. The attached archive has a reproducer
(xfs_extsize_reproducer.cc), an input op sequence (trimmed-ops.in),
the resulting file and what it should be (test, test.correct), and a
summary (notes.txt).
Thanks!
-Sam
On Wed, Jul 16, 2014 at 10:26 AM, Gregory Farnum
<gregory.farnum@xxxxxxxxxxxxx> wrote:
> On Wed, Jul 16, 2014 at 2:22 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>> On Tue, Jul 15, 2014 at 04:45:59PM -0700, Sage Weil wrote:
>>> This Firefly point release fixes an potential data corruption problem
>>> when ceph-osd daemons run on top of XFS and service Firefly librbd
>>> clients. A recently added allocation hint that RBD utilizes triggers
>>> an XFS bug on some kernels (Linux 3.2, and likely others) that leads
>>> to data corruption and deep-scrub errors (and inconsistent PGs). This
>>> release avoids the situation by disabling the allocation hint until we
>>> can validate which kernels are affected and/or are known to be safe to
>>> use the hint on.
>>
>> I've not really seen an report for that on the XFS list, could it be
>> that you're running into the issue fixed by
>>
>> "xfs: Use preallocation for inodes with extsz hints"
>>
>> (commit aff3a9edb7080f69f07fe76a8bd089b3dfa4cb5d)?
>
> Sam reported the issue we're seeing in "consequences of
> XFS_IOC_FSSETXATTR on non-empty file?", but didn't have it narrowed
> down very far. I think he's trying to get a minimal reproducer and
> identify as much as he can right now, but he's also trying to get out
> the door for a vacation. :)
>
> But yes, looking at the patch description that sounds about right.
> -Greg
reproducer.tgz
Description: GNU Zip compressed data
|