[linux-lvm] lvm utilities, metadata format, CRC (checksum)

Michael Jensen beachhangar at yahoo.com
Sat Dec 6 00:07:30 UTC 2008

Attempts to use the lvm cli tools have not proven sucessful to date.
Here's the scenario -
- A master volume is presented to the host and is init'd for use with LVM and mounted (and cannot be dismounted).
- Sometime later a storage manged snapshot is created and then mapped (presented) to the same host.  This LUN has identical data in the metadata area (1st 256 sectors).  The only blocks that are different would be where writes have been made to the master since the snapshot was taken.
- a pvscan made after the snap is available to the host reports duplicate uuid,  And it appears that it shifts the systems view of which LUN is the one representing the LVM volume if the snap LUN is a higher numbered LUN than the master.
- filtering the master out via the conf file and doing a scan (which purges cache, etc) has not helped as the master LUN is already known to LVM and is mounted.
A couple of questions -
- what is the best tool to use to search all the archive files?
- what sequence are you suggesting with the tools that will avoid the duplicate found??

--- On Fri, 12/5/08, Alasdair G Kergon <agk at redhat.com> wrote:

On Fri, Dec 05, 2008 at 07:06:03AM -0800, Michael Jensen wrote:
> Earlier attempts at being able to get a storage based snapshot on the same
server as its master failed because -
> - the master is always mounted (production)
> - the utilities recognize both master and snap and declare duplicate
> - manual edits of the header and label field failed because both are
"wrapped" with CRC that is calculated and checked by the utilities

That was obfuscated deliberately to dissuade people from thinking it's OK
edit those fields directly on disk instead of using the supplied tools!

Search the list archives - the topic comes up regularly and you can do what
you need using the command line tools.

agk at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20081205/6aa0645a/attachment.htm>

More information about the linux-lvm mailing list