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

[Michael White]

Hi Joerg & Nathan,

First thanks again to both of you for taking the time to try and explain this 
to me I very much do appreciate it.

I believe I have found a way to get the stat info you requested.  I found a 
perl one liner that appears to display the stat data.

perl -e 'print ((stat($ARGV[0]))[0]," \n");' <file>
                                                        ^ and I believe this is 
the offset to the stat fields (please correct me if I'm wrong)
                                                            I incremented this 
value (0 - 18) to get the below output
                                                            though I don't know 
why some fields are blank.

One of you talked about signed values.   And that does appear to be the case.  
See my output below using the above perl command.  The filesystem created as a 
HPUX LVM 2.2 does show a sign whereas the 1.0 version created filesytem does 
not.
So that evidently and maybe other items are causing GNU tar incremental to fail.

So now the big question.  What do I need to do to request a fix so GNU tar 
incremental will work for HPUX?  I would dearly love to use GNU tar 
incrementals on this platform.

cghbck a 2.2 vg

-2147475455            dev_t      st_dev       ID of device containing file
2                                  ino_t      st_ino       file serial number
16895                         mode_t     st_mode      mode of file
23                                nlink_t    st_nlink     number of links to 
the file
0                                  iuid_t      st_uid       user ID of file
0                                  gid_t      st_gid       group ID of file
0                                  dev_t      st_rdev      device ID (if file 
is character or block special)
2048                           off_t      st_size      file size in bytes (if 
file is a regular file)
1349100033             time_t     st_atime     time of last access
1348842113             int        st_natime    Reserved, DO NOT USE; field may 
change
1348842113             time_t     st_mtime     time of last data modification
8192                           int        st_nmtime    Reserved, DO NOT USE; 
field may change.
2                                 time_t     st_ctime     time of last status 
change
                                   int        st_nctime    Reserved, DO NOT 
USE; field may change
                                   long       st_blksize   a 
filesystem-specific preferred I/O block size
                                   blkcnt_t   st_blocks    number of blocks of 
a filesystem-specific size
                                   short      st_fstype    type of filesystem 
this file is in
                                   dev_t      st_realdev   real device number 
of device containing the inode


u01 a 1.0 vg

1076035585              dev_t      st_dev       ID of device containing file
2                                  ino_t      st_ino       file serial number
16877                        mode_t     st_mode      mode of file
5                                 nlink_t    st_nlink     number of links to 
the file
0                                 iuid_t      st_uid       user ID of file
0                                 gid_t      st_gid       group ID of file
0                                dev_t      st_rdev      device ID (if file is 
character or block special)
1024                         off_t      st_size      file size in bytes (if 
file is a regular file)
1349101214           time_t     st_atime     time of last access
1320088445           int        st_natime    Reserved, DO NOT USE; field may 
change
1320088445           time_t     st_mtime     time of last data modification
8192                         int        st_nmtime    Reserved, DO NOT USE; 
field may change.
1                               time_t     st_ctime     time of last status 
change
                                 int        st_nctime    Reserved, DO NOT USE; 
field may change
                                 long       st_blksize   a filesystem-specific 
preferred I/O block size
                                 blkcnt_t   st_blocks    number of blocks of a 
filesystem-specific size
                                 short      st_fstype    type of filesystem 
this file is in
                                dev_t      st_realdev   real device number of 
device containing the inode

Michael White

-----Original Message-----
From: Joerg Schilling [mailto:address@hidden
Sent: Saturday, September 29, 2012 6:38 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 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.

LVM is not relevant to a tar implementation.

Unlike other backup systems that only record the time of the last full or 
incremental backup, GNU tar uses a peculiar method was that is based on a file 
that holds the names of directories and their st_ino/st_dev values.

It seems that GNU tar at this point does not behave symmetrical with repect to 
reading/writing to the file that holds this information.

BTW: in order to do an incremental restore, the archive needs to hold 
st_ino/st_dev values (*) for all files in all directories that have a touched 
timestamp. AFAIR, GNU tar does not include this meta data (**) in it's archives 
and unlike star, gnu tar cannot evaluate the related information when doing 
incremental restores. As a result, incremental restores fail with GNU tar in 
some cases when a directory is replaced by another directory of the same name.

*) This meta data is usually used to build a restore symbol table that maps 
st_ino/st_dev values from the original filesystem to the related values of the 
restored filesyste.

**) GNU tar AFAIR only includes a list of names for the content of touched 
directories and whether the files for the names are included in the current 
archive, but not the needed meta data.

Hope that this background information helps to understand the problem.

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