now again a kvm-image
isn't readable again. i have to use an older snapshot to substitute the
virtual machine.
this are the entries in dmesg/kernel-log on any access:
...
[2412668.409442] btrfs csum failed ino 258 off 2331529216 csum
3632892464 private 2115348581
...
it's a product
I had a system freeze for some reason with 2.6.38.
I made a hard reboot, just to discover some of the files (KVM images, were in
use when the crash happened) on btrfs RAID-1 filesystem are corrupted:
btrfs csum failed ino 257 off 120180736 csum 4246715593 private 48329
btrfs csum failed ino 257
um' to maximize the
> performance.
>
> it happened two weeks ago for the fist time. and now again a kvm-image
> isn't readable again. i have to use an older snapshot to substitute the
> virtual machine.
>
> this are the entries in dmesg/kernel-log on any access:
>
Am 2011-05-04 02:28, schrieb Josef Bacik:
Wait why are you running with btrfs in production?
do you know a better alternative for continuous snapshots? :)
it works surprisingly well since more than a year.
well the performance could be better for vm-image-hosting but it works.
we used cache='
On Wed, May 4, 2011 at 7:44 AM, Martin Schitter wrote:
> Am 2011-05-04 02:28, schrieb Josef Bacik:
>>
>> Wait why are you running with btrfs in production?
>
> do you know a better alternative for continuous snapshots? :)
zfs :D
>
> it works surprisingly well since more than a year.
> well the p
Am 2011-05-04 04:18, schrieb Fajar A. Nugraha:
could you give me some advice how to debug/report this specific
problem more
precise?
If it's not reproducible then I'd suspect it'd be hard to do.
the last working snapshot is from 2011-05-02-17:13. i can reproduce this
file system corruption o
On Wed, May 04, 2011 at 01:39:46PM +0200, Martin Schitter wrote:
> and the 'nodatasum' option should also ignore csum issues.-- isn't it?
No, "nodatasum" will prevent newly-written data from being
checksummed. However, if a checksum already exists (because the data
was written to a filesystem
On Wed, May 4, 2011 at 5:39 AM, Martin Schitter wrote:
> Am 2011-05-04 04:18, schrieb Fajar A. Nugraha:
>>>
>>> could you give me some advice how to debug/report this specific
>>> problem more
precise?
>>
>> If it's not reproducible then I'd suspect it'd be hard to do.
>
> the last worki
Am 2011-05-04 13:51, schrieb cwillu:
that looks very unplausible to me. there is an RAID1 layer beneath btrfs in
our setup and i don't see any errors there.
That doesn't rule out the possibility of corruption when it was
written in the first place, or some similar problem that the raid1
faithfu
datasum' to maximize the
> performance.
>
> it happened two weeks ago for the fist time. and now again a kvm-image
> isn't readable again. i have to use an older snapshot to substitute the
> virtual machine.
>
> this are the entries in dmesg/kernel-log on any access:
&
Hey Martin,
On 05/04/11 13:39, Martin Schitter wrote:
Usually checksum errors is early sign of hardware failure (most
common are disk or power supply).
that looks very unplausible to me. there is an RAID1 layer beneath btrfs
in our setup and i don't see any errors there.
Is the btrfs RAID1 its
Am 2011-05-04 14:31, schrieb Kaspar Schleiser:
Is the btrfs RAID1 itself inside a virtual machine? I've had data
corruption with virtio block devices > 1TB on early squeeze kernels.
no -- it's on the (native) host side. and we use a very actual kernel
from debian 'testing' (2.6.38-2).
martin
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Martin Schitter
>
> well -- i am doing a backup of all images every night. this process
> should work like a simple "scrub" because all data (and its checksumes)
> will be read.
Sorry, not correc
Am 2011-05-04 14:39, schrieb Chris Mason:
What OS is inside these virtual machines? The btrfs unstable tree has
some fixes for windows based OSes.
we have only linux guests of different flavor, no windows guests.
both corruptions during this last weeks belong to different virtual
block devic
On 04.05.2011 13:51, cwillu wrote:
> On Wed, May 4, 2011 at 5:39 AM, Martin Schitter wrote:
>> and the 'nodatasum' option should also ignore csum issues.-- isn't it?
>
> No, it only affects writing new checksums; any existing checksums are
> still checked.
>From the report I assume this must be
On 05/03/2011 08:44 PM, Martin Schitter wrote:
Am 2011-05-04 02:28, schrieb Josef Bacik:
Wait why are you running with btrfs in production?
do you know a better alternative for continuous snapshots? :)
it works surprisingly well since more than a year.
well the performance could be better for
Am 2011-05-04 15:23, schrieb Edward Ned Harvey:
From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
ow...@vger.kernel.org] On Behalf Of Martin Schitter
well -- i am doing a backup of all images every night. this
process should work like a simple "scrub" because all data (and its
checksu
Excerpts from Martin Schitter's message of 2011-05-04 10:42:51 -0400:
> Am 2011-05-04 15:23, schrieb Edward Ned Harvey:
> >> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> >> ow...@vger.kernel.org] On Behalf Of Martin Schitter
> >>
> >> well -- i am doing a backup of all images ever
'btrfs.*fail' kern.log
Mar 27 01:07:46 mim kernel: [ 6480.233861] btrfs csum failed ino 453509 off
1495040 csum 3301532933 private 4156998194
Mar 27 01:07:46 mim kernel: [ 6480.234470] btrfs csum failed ino 453509 off
1499136 csum 1873118812 private 3512102188
Mar 27 01:07:46
On Tue, 27 Mar 2012 12:57:31 +0200
Christoph Groth wrote:
> root@mim:/# find / -inum 453509 -ls
> 453509 1976 -rw-r--r-- 1 root root 2020832 Mar 7 21:11
> /usr/lib/libreoffice/basis3.4/program/libsblx.so
>
> That file seems to be ok, there are no errors when re-reading it.
How abou
Roman Mamedov writes:
> On Tue, 27 Mar 2012 12:57:31 +0200
> Christoph Groth wrote:
>
>> root@mim:/# find / -inum 453509 -ls
>> 453509 1976 -rw-r--r-- 1 root root 2020832 Mar 7 21:11
>> /usr/lib/libreoffice/basis3.4/program/libsblx.so
>>
>> That file seems to be ok, there are no er
age appeared in
> kern.log. There were no other errors.
>
> root@mim:/var/log# grep 'btrfs.*fail' kern.log
> Mar 27 01:07:46 mim kernel: [ 6480.233861] btrfs csum failed ino 453509 off
> 1495040 csum 3301532933 private 4156998194
> Mar 27 01:07:46 mim kernel: [ 64
On 27.03.2012 18:24, cwillu wrote:
> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth wrote:
>> A scrub done the morning after the incident also didn't find any
>> problems:
>>
>> root@mim:/home/cwg# btrfs scrub status /
>> scrub status for 2da00153-f9ea-4d6c-a6cc-10c913d22686
>>scrub star
Jan Schmidt writes:
> On 27.03.2012 18:24, cwillu wrote:
>> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth wrote:
>>> A scrub done the morning after the incident also didn't find any
>>> problems:
>>>
>>> root@mim:/home/cwg# btrfs scrub status /
>>> scrub status for 2da00153-f9ea-4d6c-a6cc-10c9
Just got this error today in my dmesg:
btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798
linux % find . -inum 1483065
./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
It's the main pack file from my git linux kernel tree:
linux % ls -l .
,x-systemd.automount,nofail
/var UUID=0d7a2474-3523-413e-8611-1f489b8a9891 btrfs
subvol=var,ssd,compress=lzo
/usr UUID=0d7a2474-3523-413e-8611-1f489b8a9891 btrfs
subvol=usr,ssd,compress=lzo
Errors reported in dmesg:
[10520.530437] btrfs csum failed ino 1988603 off 1277952 csum
256647207
On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
> On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > Just got this error today in my dmesg:
> > > btrfs csum failed ino 1483065 off 158482432 csum 4283543
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
> On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
> > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > Just got this error today i
On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> Just got this error today in my dmesg:
> btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798
>
> linux % find . -inum 1483065
> ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack
>
&g
On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > Just got this error today in my dmesg:
> > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798
> >
> > linux % find . -inum 1483
On Tue, Sep 08, 2009 at 10:22:11PM +0200, Markus Trippelsdorf spake thusly:
> I've already deleted the file in question unfortunately.
> On IRC Chris decided that either bad RAM or a harddrive error was the
> most likely reason for this chechsum mismatch.
Which raises an interesting point: I know
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
> On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
> > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > Just got this error today i
pelsdorf wrote:
> > > > > Just got this error today in my dmesg:
> > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private
> > > > > 43905798
> > > > >
> > > > > linux % find . -inum 1483065
> >
0:42PM +0200, Jens Axboe wrote:
> > > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > > > Just got this error today in my dmesg:
> > > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private
> > > > > >
ippelsdorf wrote:
> > > > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > > > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > > > > Just got this error today in my dmesg:
> > > > &
On Tue, Sep 8, 2009 at 5:53 PM, Tracy Reed wrote:
> On Tue, Sep 08, 2009 at 10:22:11PM +0200, Markus Trippelsdorf spake thusly:
>> I've already deleted the file in question unfortunately.
>> On IRC Chris decided that either bad RAM or a harddrive error was the
>> most likely reason for this chechsu
s Axboe wrote:
>> > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
>> > > > > Just got this error today in my dmesg:
>> > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private
>> > > > &
> >> > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> >> > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> >> > > > > Just got this error today in my dmesg:
> >> > > > > btrfs csum failed ino 14
e:
>> >> > On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
>> >> > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
>> >> > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
>> >> > > > > Just
On Wed, Sep 09, 2009 at 09:37:42AM +0100, Daniel J Blueman wrote:
> >>
> >> http://www.ocztechnologyforum.com/forum/showthread.php?t=57516
> >
> > The issue is pretty much moot at this point, since OCZ support were not
> > really interested in providing any sort of real technical support to
> > fin
What a strange coincidence that it affected git pack files in both cases.
It's almost too improbable...
Probably more than a coincidence I think, the question is what though...
Some SSD drives (or rather the cheap wear levelling controllers in things
like USB sticks) have firmware which tri
On Wed, Sep 9, 2009 at 11:01 PM, Oliver Mattos
wrote:
>
>>> What a strange coincidence that it affected git pack files in both cases.
>>> It's almost too improbable...
>
I had similar problems with a broken git repository about two weeks
ago. This was on a regular laptop harddrive that's never rep
On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > Just got this error today in my dmesg:
> > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798
> >
> > linux % find . -inum 1483
On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
> On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > Just got this error today in my dmesg:
> > > btrfs csum failed ino 1483065 off 158482432 csum 4283543
>
> > > > It's the main pack file from my git linux kernel tree:
> > > >
> > >
> > > Hmm, I ran into something very similar. Care to check what the corrupted
> > > block of data looks like (and how big it is)?
> >
> > I'
pelsdorf wrote:
> > > > > Just got this error today in my dmesg:
> > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private
> > > > > 43905798
> > > > >
> > > > > linux % find . -inum 1483065
> >
0:42PM +0200, Jens Axboe wrote:
> > > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > > > Just got this error today in my dmesg:
> > > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private
> > > > > >
p 17 2009, Markus Trippelsdorf wrote:
> > > > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > > > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > > > > > Just got this error today in my dmesg:
> > > > &
> 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 B7 FD AB DA 74 2D 1C
> 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 33 FD AB DA 74 2D 1C
B7 = 10110111
33 = 00110011
> 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 5E 7E EB DA 5F D6 11
> 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 1E 7E EB DA 5F D6 11
5E = 0100
1E =
On Thu, Sep 17, 2009 at 10:00:28AM -0700, Zach Brown wrote:
>
> > 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 B7 FD AB DA 74 2D 1C
> > 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 33 FD AB DA 74 2D 1C
>
> B7 = 10110111
> 33 = 00110011
>
> > 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 5E 7E EB DA 5F D6 11
> > 06
On Thu, Sep 17, 2009 at 07:10:06PM +0200, Markus Trippelsdorf wrote:
> > > 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A
> > > 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A
> >
> > 4B = 01001011
> > 0B = 1011
> >
> > And so on.
> >
> > It looks like a few bits are
s=lzo,x-systemd.automount,nofail
> /var UUID=0d7a2474-3523-413e-8611-1f489b8a9891 btrfs
> subvol=var,ssd,compress=lzo
> /usr UUID=0d7a2474-3523-413e-8611-1f489b8a9891 btrfs
> subvol=usr,ssd,compress=lzo
>
>
>
> Errors reported in dmesg:
>
> [10520.530437] btrfs
52 matches
Mail list logo
