Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems

[Michael White]

Hi Joerg,

Thanks for responding.
I'm not sure I understand your reply.  Maybe I'm not explaining it correctly.
I am not talking about tar archive format, more so the metadata value in the 
snapshot file format.  What I believe I'm running into is tar's in ability to 
do "incremental backups" on HP-UX Intel(R) Itanium because it (tar) doesn't 
understand HP-UX LVM version 2.2 volume group/filesystems metadata.  I think 
HP-UX LVM 2.0 came out in HP's OS release March 2010.
For incrementals tar is checking the tar snapshot file but halts immediately 
with the error "Unexpected field value in snapshot file".  I only get this 
error if trying to do an incremental.  When I run "tar-snapshot-edit" it calls 
out this one directory saying the dev value is too high, but only if it is a 
HP-UX LVM 2.2 version.  If I recreate the filesystem (Vxfs) as LVM version 1.0 
I do not get the snapshot error.  And I believe the reason is the device meta 
data is totally different between LVM 1.0 and LVM 2.2 as shown by the map file 
info below.  And basically it (tar) can't find the date timestamp in the 
snapshot file because of the difference between LVM 1.0 and LVM 2.0 metadata.
Does that make more sense to you?

Michael White

-----Original Message-----
From: Joerg Schilling [mailto:address@hidden
Sent: Friday, September 28, 2012 6:34 AM
To: address@hidden; Michael White; address@hidden
Subject: Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems

Michael White <address@hidden> wrote:

> Hi Nathan,
>
> Thanks for the reply.  Yes, it should have said "directory".
> You're going to have help me out a bit as I don't understand what you're 
> asking for re. "stat <path-to-volume>/cghbck".
> I do not see a OS stat command, there is a programmable stat (5) but I'm not 
> a programmer that would know how to use it.
> Are you asking for the path to the disk or the VG ID?
> The path to the disk in both LVM v1 & v2 is the same LUN H/W Path
> 64000/0xfa00/0x22 I think the VG ID you're looking for and it is quite 
> different.
>
> LVM 1:
> # cat /cghbck/disk35.map
> VGID 792e94cf50649f50
>
> LVM 2.2:
> # cat /cghbck/disk35.map2
> MAPFILE02
> VGID A0000000000000017Fri Sep 28 02:40:28
> 2012792e94cf-f555-11dd-b66b-e1cbc018d4fd
>
> I obtained this info by vgexport to a map file.  I know for LVM 1 the VG ID 
> hex first 8 = machine ID (uname -i) and the 2nd 8 hex is time stamp.  For LVM 
> 2 I do not know the format, still researching.
> I did fine this info that may be helpful.
> In volume groups version 1.0, LVM metadata is required to fit into a
> single physical extent. In volume groups version 2.0 and higher, metadata is 
> not restricted to an extent.
>
> So I'm assuming GNU Tar doesn't know how to handle the HP-UX LVM 2.2 metadata 
> since it is not restricted to a single extent.  Would that be a fair 
> assumption?

This text does not seem to be related to the tar archive format nor to UNIX, 
what are you talking about?


>
> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Nathan Stratton 
> Treadway
> Sent: Thursday, September 27, 2012 4:49 PM
> To: address@hidden
> Subject: Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems
>
> On Thu, Sep 27, 2012 at 20:05:38 +0000, Michael White wrote:
> > I got the tar-snapshot-edit utility and it calls out this file system.
> >
> > Director: /cghbck
> >                 Dev value too high: "18446744071562076161" >
> > 4294967295

If you use a tar archive for what is in the standard, then dev_t values are only
archived for block and char devices.

If this is related to incremental backups, things look different as then there
is a need to remember dev_t.

Unfortunately dev_t may be signed and if you check 18446744071562076161, it
looks like there was a sing extension....

Did you try to use star?

A recent version is in:

ftp://ftp.berlios.de/pub/schily/

Jörg

--
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

****************************************************************************************************
CONFIDENTIALITY NOTICE
This communication and any files or attachments transmitted with it may
contain information that is confidential, privileged and exempt from disclosure 
under
applicable law. It is intended solely for the use of the individual or entity 
to which it is
addressed. If you are not the intended recipient, you are hereby notified that 
any use,
dissemination, copying, or action taken in reliance on the contents of this
communication is strictly prohibited. If you have received this communication 
in error,
please promptly delete it and notify the sender of the delivery error by e-mail 
so that
the appropriate action may be taken to avoid troubling you further.
Thank you for your cooperation. V2
****************************************************************************************************