Well,
nobody able to sched some light in?
Did some math and found out how to fill the size bytes.
But, one question never got answered:
- why is - with busy VMs - frequently the first block affected,
with the result of damaged grub-loaders/partition-tables/filesystems?
Is this some NULL/zero pointer thingy in case of ceph-failure?
If you demand some broken images… we have many of them to investigate,
unfortunately.
Maybe this sounds a bit harsh, after the 5th night-shift trying to repair images
and keep customers calm, I think this is forgivable.
Oliver.
Am 14.03.2012 um 16:05 schrieb Oliver Francke:
> Hey,
>
> anybody out there who could explain the structure of a rbd-header? After
> last crash we have about 10 images with a:
> 2012-03-14 15:22:47.998790 7f45a61e3760 librbd: Error reading
> header: 2 No such file or directory
> error opening image vm-266-disk-1.rbd: 2 No such file or directory
> ... error?
> I understand the "rb.x.y"-prefix, the 2 ^ 16hex as block-size. But
> the size/count encoding is not intuitive ;)
>
> Besides one file, where I "created" a header and putted it via "rados
> put" back into the pool, and got some files
> back, many of the other images with lost headers have different sizes.
>
> We got bad luck again, too many crashed VM's, too much data-loss...
>
> Comments welcome ;)
>
> Oliver.
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
