[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fwd: [help] how to deal with Incorrect metadata area header checksum in LVM

max wrote:
Robin Laing wrote:
max wrote:
Zhen Zhou wrote:
On Wed, Jun 11, 2008 at 8:45 PM, David Timms <dtimms iinet net au> wrote:
Zhen Zhou wrote:
So what is the right path to recover these lvm?

Any tips will be welcome! Thanks in advanced,

BTW: the attached is lvm metadata file. More detail information
needed, pls tell me.
You might find experts in LVM hanging out on:
linux-lvm redhat com [subscription required].

Good luck.
FTA, thanks for your tips.
and I really wonder whether these errors "Incorrect metadata area
header checksum,
Volume group VolGroup00 metadata is inconsistent" is impossible to recover.

Or what I need to deal, is to follow:
to recover all lvm's data?

Any tips will be welcome. TIA

Zhou Zhen

I asked in a related thread on the developer's list and I'll ask here. Someone please let me know if my question doesn't make any sense. Is it harder to recover files from an LVM than with the older partioning scheme?

FWIW, I did recover data from an LVM that was removed (on purpose) in part of an upgrade. I couldn't mount the drive as the LVM recovery procedures listed and I thought I was toast. If I left the drive in the computer, the computer would try to add the drive back into the LVM no matter what I tried.

To complicate things even further, the drive was part of a RAID 1 array. I put the drive into a carrier. As the drive was SATA, I ended up getting a Thermaltake carrier that supports SATA and IDE (end product plug). :)

It was many months ago but I used normal recovery tools to pull the data off of the drive. I would have to look at my notes which are at home. If I remember I will see if I can find my notes.

Basically, it is possible but I don't know if it is harder as this was my first time.

I suspect it is more difficult by comparison but I could easily be misinterpreting what I am reading. For instance this appears on wikipedia at the end of the LVM entry.


The current implementation does not support write barriers. This means that any guarantee against filesystem corruption offered by journaled file systems like ext3 and XFS is negated.

It seems to imply that a lack of support for write barriers may be more likely to cause/lead to/result in/not protect against corruption and therefore by extension make data recovery more difficult in particular cases. Though whether support for write barriers is now present I don't know. I have learned a bit about file operations in searching but I am still not clear on what a write barrier is, though I think I am getting close, if you know of some place I can find a factual definition that would be great because I have found many instances of people discussing them but obviously both parties know what it is and so they never have to or bother to agree on a common definition.If you can explain what a write barrier is then that would be even cooler. I feel like I have most of the pieces but I am missing the lynch pin that will hold it all together. Though its just as likely that the answer will cause me more confusion but I won't know until I find it.

Here is the url to the entry:(its not very long)

Funny but I think I have found my answer, right under my nose as usual : )
Thanks for responding though because I probably wouldn't have seen it otherwise.

Fortune favors the BOLD

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]