From: Guido Winkelmann <guido-ceph@thisisnotatest.de>
To: Sage Weil <sage@inktank.com>
Cc: Oliver Francke <Oliver.Francke@filoo.de>,
Josh Durgin <josh.durgin@inktank.com>,
ceph-devel@vger.kernel.org
Subject: Re: Random data corruption in VM, possibly caused by rbd
Date: Mon, 11 Jun 2012 17:50:14 +0200 [thread overview]
Message-ID: <25761303.PmWYZprmzc@pc10> (raw)
In-Reply-To: <Pine.LNX.4.64.1206080652031.10292@cobra.newdream.net>
Am Freitag, 8. Juni 2012, 06:55:19 schrieb Sage Weil:
> On Fri, 8 Jun 2012, Oliver Francke wrote:
> > Hi Guido,
> >
> > yeah, there is something weird going on. I just started to establish some
> > test-VM's. Freshly imported from running *.qcow2 images.
> > Kernel panic with INIT, seg-faults and other "funny" stuff.
> >
> > Just added the rbd_cache=true in my config, voila. All is
> > fast-n-up-n-running...
> > All my testing was done with cache enabled... Since our errors all came
> > from rbd_writeback from former ceph-versions...
>
> Are you guys able to reproduce the corruption with 'debug osd = 20' and
> 'debug ms = 1'? Ideally we'd like to:
>
> - reproduce from a fresh vm, with osd logs
> - identify the bad file
> - map that file to a block offset (see
> http://ceph.com/qa/fiemap.[ch], linux_fiemap.h)
> - use that to identify the badness in the log
>
> I suspect the cache is just masking the problem because it submits fewer
> IOs...
Okay, I added 'debug osd = 20' and 'debug ms = 1' under [global] and
'filestore fiemap = false' under [osd] and started a new VM. That worked
nicely, and the iotester found no corruptions. Then I removed 'filestore
fiemap = false' from the config, restarted all osds and ran the iotester
again. Output is as follows:
testserver-rbd11 iotester # date ; ./iotester /var/iotest ; date
Mon Jun 11 17:34:44 CEST 2012
Wrote 100 MiB of data in 1943 milliseconds
Wrote 100 MiB of data in 1858 milliseconds
Wrote 100 MiB of data in 2213 milliseconds
Wrote 100 MiB of data in 3441 milliseconds
Wrote 100 MiB of data in 2705 milliseconds
Wrote 100 MiB of data in 1778 milliseconds
Wrote 100 MiB of data in 1974 milliseconds
Wrote 100 MiB of data in 2780 milliseconds
Wrote 100 MiB of data in 1961 milliseconds
Wrote 100 MiB of data in 2366 milliseconds
Wrote 100 MiB of data in 1886 milliseconds
Wrote 100 MiB of data in 3589 milliseconds
Wrote 100 MiB of data in 1973 milliseconds
Wrote 100 MiB of data in 2506 milliseconds
Wrote 100 MiB of data in 1937 milliseconds
Wrote 100 MiB of data in 3404 milliseconds
Wrote 100 MiB of data in 1990 milliseconds
Wrote 100 MiB of data in 3713 milliseconds
Read 100 MiB of data in 4856 milliseconds
Digest wrong for file "/var/iotest/b45e1a59f26830fb98af1ba9ed1360106f5580aa"
Mon Jun 11 17:35:34 CEST 2012
testserver-rbd11 iotester # ~/fiemap
/var/iotest/b45e1a59f26830fb98af1ba9ed1360106f5580aa
File /var/iotest/b45e1a59f26830fb98af1ba9ed1360106f5580aa has 1 extents:
# Logical Physical Length Flags
0: 0000000000000000 00000000a8200000 0000000000100000 000
I looked into the file in question, and it started with zero-bytes from the
start until position 0xbff, even though it was supposed to all random data.
I have included timestamps in the hopes they might make it easier to find the
related entries in the logs.
So what do I do now? The logs are very large and complex, and I don't
understand most of what's in there. I don't even know which OSD served that
particular block/object.
Regards,
Guido
next prev parent reply other threads:[~2012-06-11 15:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 18:04 Random data corruption in VM, possibly caused by rbd Guido Winkelmann
2012-06-07 18:18 ` Stefan Priebe
2012-06-07 18:37 ` Guido Winkelmann
2012-06-07 19:54 ` Andrey Korolyov
2012-06-07 21:03 ` Guido Winkelmann
2012-06-07 21:53 ` Marcus Sorensen
2012-06-07 22:12 ` Guido Winkelmann
2012-06-07 18:40 ` Oliver Francke
2012-06-07 19:48 ` Josh Durgin
2012-06-07 21:36 ` Guido Winkelmann
2012-06-07 22:13 ` Tommi Virtanen
2012-06-08 12:55 ` Guido Winkelmann
2012-06-08 13:08 ` Guido Winkelmann
2012-06-08 13:36 ` Oliver Francke
2012-06-08 13:55 ` Sage Weil
2012-06-08 14:50 ` Josh Durgin
2012-06-08 15:39 ` Oliver Francke
2012-06-08 17:15 ` Guido Winkelmann
2012-06-10 3:04 ` Sage Weil
2012-06-10 3:07 ` Sage Weil
2012-06-11 14:15 ` Guido Winkelmann
2012-06-11 15:50 ` Guido Winkelmann [this message]
2012-06-11 16:30 ` Sage Weil
2012-06-11 17:07 ` Guido Winkelmann
2012-06-11 17:12 ` Sage Weil
2012-06-11 17:29 ` Josh Durgin
2012-06-12 12:31 ` Guido Winkelmann
2012-06-15 12:14 ` Stefan Majer
2012-06-15 15:38 ` Josh Durgin
2012-06-15 18:50 ` Josh Durgin
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=25761303.PmWYZprmzc@pc10 \
--to=guido-ceph@thisisnotatest.de \
--cc=Oliver.Francke@filoo.de \
--cc=ceph-devel@vger.kernel.org \
--cc=josh.durgin@inktank.com \
--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.