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

[Joerg Schilling]

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