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
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
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
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
since my last debian kernel-update to 2.6.38-2-amd64 i got troubles with
csum failures. it's a volume full of huge kvm-images on md-RAID1 and
LVM, so i used the mount options: 'noatime,nodatasum' to maximize the
performance.
it happened two weeks ago for the fist time. and now again a
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
