From: Dave Chinner <david@fromorbit.com>
To: Gregory Farnum <gregory.farnum@dreamhost.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
Sage Weil <sage@inktank.com>, Samuel Just <sam.just@inktank.com>,
xfs@oss.sgi.com
Subject: Re: v0.80.4 Firefly released
Date: Thu, 17 Jul 2014 08:31:50 +1000 [thread overview]
Message-ID: <20140716223150.GE4453@dastard> (raw)
In-Reply-To: <CAPYLRziqpnjHbViaFw2MtXcYKiCDE9wz8qaqiQjAJGDoUbG7cg@mail.gmail.com>
On Wed, Jul 16, 2014 at 10:26:23AM -0700, Gregory Farnum wrote:
> On Wed, Jul 16, 2014 at 2:22 AM, Christoph Hellwig <hch@infradead.org> 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?",
Assuming you've created an extent size hint with a file with delayed
allocation on it and no blocks, then that's more than likely the
same issue. The above commit uses preallocation to allocate
unwritten extents rather than delayed allocation for files with
extent size hints because delayed allocation doesn't write zeros
over ranges in the allocated extents that don't have dirty data over
them.
Moral of the story: any time you get what appears to be data
corruption in the underlying data store, you should report it to the
relevant filesystem list rather than try to work around it....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-07-16 22:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.2.00.1407151634250.21336@cobra.newdream.net>
2014-07-16 9:22 ` v0.80.4 Firefly released Christoph Hellwig
2014-07-16 17:26 ` Gregory Farnum
2014-07-16 22:31 ` Dave Chinner [this message]
2014-07-16 23:41 ` Samuel Just
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140716223150.GE4453@dastard \
--to=david@fromorbit.com \
--cc=ceph-devel@vger.kernel.org \
--cc=gregory.farnum@dreamhost.com \
--cc=hch@infradead.org \
--cc=sage@inktank.com \
--cc=sam.just@inktank.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox