bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathan Stratton Treadway
Subject: Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems
Date: Fri, 28 Sep 2012 15:16:56 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]