From: Oliver Francke <Oliver.Francke@filoo.de>
To: Sage Weil <sage@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: all rbd users: set 'filestore fiemap = false'
Date: Mon, 18 Jun 2012 10:29:15 +0200 [thread overview]
Message-ID: <4FDEE6DB.8030406@filoo.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1206172053320.16985@cobra.newdream.net>
Hi Sage,
On 06/18/2012 06:02 AM, Sage Weil wrote:
> If you are using RBD, and want to avoid potential image corruption, add
>
> filestore fiemap = false
>
> to the [osd] section of your ceph.conf and restart your OSDs.
as far as this heals some trouble, but I fairly don't understand...
>
> We've tracked down the source of some corruption to racy/buggy FIEMAP
> ioctl behavior. The RBD client (when caching is diabled--the default)
> uses a 'sparse read' operation that the OSD implements by doing an fsync
> on the object file, mapping which extents are allocated, and sending only
> that data over the wire. We have observed incorrect/changing FIEMAP on
> both btrfs:
>
> fsync
> fiemap returns mapping
> <time passes, no modifications to file>
> fiemap returns different mapping
... that even an initial start of a VM leads to corruption of the read data?
I get s/t like:
--- 8-< ---
Loading, please wait
/sbin/init: relocation error: ...
not defined in file libc.so.6...
[ 0.81...] Kernel panic - not snycing: Attempted to kill init!
--- 8-< ---
host-kernel is now 3.4.1 + qemu-1.0.1, but shows failures with other
kernel/qemu-versions, too.
Keeping fingers crossed for Josh, though ;-)
Give me a shout, If I can do some debugging,
regards,
Oliver.
>
> Josh is still tracking down which kernels and file system are affected;
> fortunately it is relatively easy to reproduce with the test_librbd_fsx
> tool. In the meantime, the (mis)feature can be safely disabled. It will
> default to off in 0.48. It is unclear whether it's really much of a
> performance win anyway.
>
> Thanks!
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Oliver Francke
filoo GmbH
Moltkestraße 25a
33330 Gütersloh
HRB4355 AG Gütersloh
Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz
Folgen Sie uns auf Twitter: http://twitter.com/filoogmbh
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-06-18 8:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 4:02 all rbd users: set 'filestore fiemap = false' Sage Weil
2012-06-18 8:29 ` Oliver Francke [this message]
2012-06-18 8:57 ` Christoph Hellwig
2012-06-18 15:32 ` Sage Weil
2012-06-22 15:16 ` Christoph Hellwig
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=4FDEE6DB.8030406@filoo.de \
--to=oliver.francke@filoo.de \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@inktank.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.