[Bug 1598443] [NEW] tar mistakenly thinks two distinct files on a zfs volume are hard linked

Sat Jul 2 14:55:04 UTC 2016

Public bug reported:

I performed a backup to tape of three ZFS filesystem snapshots with this command:
tar -cPvzf /dev/st0 /tambor/luki/.zfs/snapshot/backup/ /tambor/caligrafix/.zfs/snapshot/backup/ /tambor/pub/.zfs/snapshot/backup/

Then when verifying the backup with this command:
tar -dPvzf /dev/st0 /tambor/luki/.zfs/snapshot/backup/ /tambor/caligrafix/.zfs/snapshot/backup/ /tambor/pub/.zfs/snapshot/backup/ 

I got errors such as:
/tambor/pub/.zfs/snapshot/backup/gallery.img: Not linked to /tambor/pub/.zfs/snapshot/backup/gallery.img

Listing the archive content for this entry shows that tar thought there was a hard link:
hrw------- libvirt-qemu/kvm            0 2016-06-30 16:42 /tambor/pub/.zfs/snapshot/backup/gallery.img link to tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2

On the actual filesystem, stat shows the following about these files:

gpothier at lerne:~$ stat /tambor/pub/.zfs/snapshot/backup/gallery.img
  File: '/tambor/pub/.zfs/snapshot/backup/gallery.img'
  Size: 21474836480	Blocks: 38391905   IO Block: 131072 regular file
Device: 28h/40d	Inode: 9           Links: 1
Access: (0600/-rw-------)  Uid: (  106/libvirt-qemu)   Gid: (  106/     kvm)
Access: 2016-06-14 08:17:12.243476594 -0400
Modify: 2016-06-30 16:42:05.151696559 -0400
Change: 2016-06-30 16:42:05.151696559 -0400
 Birth: -
gpothier at lerne:~$ stat /tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2
  File: '/tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2'
  Size: 152349835264	Blocks: 39049233   IO Block: 131072 regular file
Device: 29h/41d	Inode: 9           Links: 1
Access: (0600/-rw-------)  Uid: (  106/libvirt-qemu)   Gid: (  106/     kvm)
Access: 2016-06-14 08:17:12.711478957 -0400
Modify: 2016-06-30 16:42:08.691712436 -0400
Change: 2016-06-30 16:42:08.691712436 -0400
 Birth: -

They have the same inode number, but a different device number. And their link count is 1.
So the heuristics tar uses to determine if a file is a hard link are not correct. In this case this is a big deal, as it produced an incomplete backup. I will have to use the --hard-dereference flag to work around it.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: tar 1.27.1-1
ProcVersionSignature: Ubuntu 3.13.0-88.135-generic 3.13.11-ckt39
Uname: Linux 3.13.0-88-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
Date: Sat Jul  2 10:43:43 2016
InstallationDate: Installed on 2014-05-29 (764 days ago)
InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
SourcePackage: tar
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: tar (Ubuntu)
     Importance: Undecided
         Status: New

** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to tar in Ubuntu.
https://bugs.launchpad.net/bugs/1598443

Title:
  tar mistakenly thinks two distinct files on a zfs volume are hard
  linked

Status in tar package in Ubuntu:
  New

Bug description:
  I performed a backup to tape of three ZFS filesystem snapshots with this command:
  tar -cPvzf /dev/st0 /tambor/luki/.zfs/snapshot/backup/ /tambor/caligrafix/.zfs/snapshot/backup/ /tambor/pub/.zfs/snapshot/backup/

  Then when verifying the backup with this command:
  tar -dPvzf /dev/st0 /tambor/luki/.zfs/snapshot/backup/ /tambor/caligrafix/.zfs/snapshot/backup/ /tambor/pub/.zfs/snapshot/backup/ 

  I got errors such as:
  /tambor/pub/.zfs/snapshot/backup/gallery.img: Not linked to /tambor/pub/.zfs/snapshot/backup/gallery.img

  Listing the archive content for this entry shows that tar thought there was a hard link:
  hrw------- libvirt-qemu/kvm            0 2016-06-30 16:42 /tambor/pub/.zfs/snapshot/backup/gallery.img link to tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2

  On the actual filesystem, stat shows the following about these files:

  gpothier at lerne:~$ stat /tambor/pub/.zfs/snapshot/backup/gallery.img
    File: '/tambor/pub/.zfs/snapshot/backup/gallery.img'
    Size: 21474836480	Blocks: 38391905   IO Block: 131072 regular file
  Device: 28h/40d	Inode: 9           Links: 1
  Access: (0600/-rw-------)  Uid: (  106/libvirt-qemu)   Gid: (  106/     kvm)
  Access: 2016-06-14 08:17:12.243476594 -0400
  Modify: 2016-06-30 16:42:05.151696559 -0400
  Change: 2016-06-30 16:42:05.151696559 -0400
   Birth: -
  gpothier at lerne:~$ stat /tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2
    File: '/tambor/luki/.zfs/snapshot/backup/vms/luki-odoo.qcow2'
    Size: 152349835264	Blocks: 39049233   IO Block: 131072 regular file
  Device: 29h/41d	Inode: 9           Links: 1
  Access: (0600/-rw-------)  Uid: (  106/libvirt-qemu)   Gid: (  106/     kvm)
  Access: 2016-06-14 08:17:12.711478957 -0400
  Modify: 2016-06-30 16:42:08.691712436 -0400
  Change: 2016-06-30 16:42:08.691712436 -0400
   Birth: -

  They have the same inode number, but a different device number. And their link count is 1.
  So the heuristics tar uses to determine if a file is a hard link are not correct. In this case this is a big deal, as it produced an incomplete backup. I will have to use the --hard-dereference flag to work around it.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: tar 1.27.1-1
  ProcVersionSignature: Ubuntu 3.13.0-88.135-generic 3.13.11-ckt39
  Uname: Linux 3.13.0-88-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  Date: Sat Jul  2 10:43:43 2016
  InstallationDate: Installed on 2014-05-29 (764 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
  SourcePackage: tar
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1598443/+subscriptions