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

[max]

Robin Laing wrote:
> max wrote:
>> Zhen Zhou wrote:
>>> On Wed, Jun 11, 2008 at 8:45 PM, David Timms <dtimms at 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 at 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:
>>> http://thread.gmane.org/gmane.linux.redhat.fedora.general/196481
>>> 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.

> Caveats
> 
> 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)
> http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)



-- 
Fortune favors the BOLD