Michael White <[email protected]> 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: [email protected] > [mailto:[email protected]] On Behalf Of Nathan > Stratton Treadway > Sent: Thursday, September 27, 2012 4:49 PM > To: [email protected] > 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:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
