xfs
[Top] [All Lists]

Re: v0.80.4 Firefly released

To: Gregory Farnum <gregory.farnum@xxxxxxxxxxxxx>
Subject: Re: v0.80.4 Firefly released
From: Samuel Just <sam.just@xxxxxxxxxxx>
Date: Wed, 16 Jul 2014 11:52:08 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Sage Weil <sage@xxxxxxxxxxx>, "ceph-devel@xxxxxxxxxxxxxxx" <ceph-devel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAPYLRziqpnjHbViaFw2MtXcYKiCDE9wz8qaqiQjAJGDoUbG7cg@xxxxxxxxxxxxxx>
References: <alpine.DEB.2.00.1407151634250.21336@xxxxxxxxxxxxxxxxxx> <20140716092226.GA23561@xxxxxxxxxxxxx> <CAPYLRziqpnjHbViaFw2MtXcYKiCDE9wz8qaqiQjAJGDoUbG7cg@xxxxxxxxxxxxxx>
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

Attachment: reproducer.tgz
Description: GNU Zip compressed data

<Prev in Thread] Current Thread [Next in Thread>