Robin Laing wrote:
max wrote:
Zhen Zhou wrote:
On Wed, Jun 11, 2008 at 8:45 PM, David Timms <dtimms@xxxxxxxxxxxx>
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@xxxxxxxxxx [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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
