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

[Joerg Schilling]

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