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 <[email protected]>" 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: [email protected] [mailto:[email protected]] On Behalf Of Nathan Stratton Treadway Sent: Friday, September 28, 2012 2:17 PM To: [email protected] 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 - [email protected] - 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 ****************************************************************************************************
