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

[Michael White]

Thanks Nathan for your patience and explanations.  I will try to find out how 
to get the info you seek re. stat.
I think maybe I've confused the issue by talking about VG's and LVM.  But HP's 
LVM version 2.2 for sure has changed the way it writes metadata on the files 
which is breaking GNU tar's incremental operation.  I think that's evident by 
the tar-snapshot-edit utility check of the field values of the snapshot file.   
When it hits a filesystem that has been initialized as a HP LVM 2.2.  I get the 
" Dev value too high" error otherwise I don't get the error.
eg:                Dev value too high: "18446744071562076161" > 4294967295

But the tar-snapshot-edit utility calls out every file and directory like above 
as well if the filesystem was initialized as a HP LVM 2.2

Would it help any if you saw the snapfile?

On additional note, do you know who has been porting GNU tar to The Porting And 
Archive Centre for HP-UX in the United Kingdom?  This where I get GNU and other 
packages for HP-UX.  The info on that site for the tar package says "Author: 
Francois Pinard <address@hidden>" but I don't know if that's the person that 
ported it to HP-UX.  Possibly they could shed additional light on the issue.

Thank again Nathan.

Michael

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Nathan Stratton 
Treadway
Sent: Friday, September 28, 2012 2:17 PM
To: address@hidden
Subject: Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems

On Fri, Sep 28, 2012 at 03:27:06 +0000, Michael White wrote:
> 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?
[...]
> 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?

GNU tar actually doesn't know anything at all about LVM metadata, or about any 
other "substructure" underlying the directory tree that you are trying to back 
up.

What it does look at is the "device number" that the filesystem reports for 
each file or directory is getting backed up.  Tar records that number along 
with the inode number in the snapshot file, because those two values form a 
sort of unique key for a particular object on the filesystem.  (Probably the 
stat man page that you found on your system documents the internal C data 
structure used by for this information; in particular, GNU tar uses the 
"st_dev" and "st_ino" fields.)

Anyway, the important point is that this device number is not directly related 
to anything about the LVM volume or associated metadata, but is a standard part 
of mounting any sort of filesystem under Unix.  However, it does seem like in 
the case of your LVM 2.2 volumes, the device number that's getting used by the 
mounted filesystem is triggering some sort of bug in GNU tar.

The "stat" command I was asking about simply prints out the "raw" info from the 
stat structure for a particular filesystem object.  So for example on my linux 
system I have:

# stat /
  File: `/'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 900h/2304d      Inode: 2           Links: 24
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-28 02:15:11.719222985 -0400
Modify: 2012-09-20 09:31:02.843152102 -0400
Change: 2012-09-20 09:31:02.843152102 -0400
 Birth: -

# stat /data
  File: `/data'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 901h/2305d      Inode: 2           Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-28 02:15:11.719222985 -0400
Modify: 2012-06-01 09:32:42.451604150 -0400
Change: 2012-06-01 09:32:42.451604150 -0400
 Birth: -

Note in particular the Device: field on the third line, which in this example 
shows that /data a separate filesystem from / (since the device numbers are 
different).

Unfortunately I don't know what the equivalent command on HP/UX would be, but 
basically the idea is simply to figure out what device number the "stat" 
function is returning for the filesystems you are mounting on LVM volumes, with 
the hope that knowing that info might give a hint as to what's happening within 
GNU Tar in that case.

                                                        Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  address@hidden  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


****************************************************************************************************
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
****************************************************************************************************