Bug 232462

Description of problem:
Near total incompatibility with any kernel in the 2.6.21-rc* group.

Version-Release number of selected component (if applicable):
tar-1.15.1-24.fc6


How reproducible:
Boot to any of the .21-rc* kernels, fire off a run of amanda, the backup utility.

Steps to Reproduce:
1. Boot to any 2.6.21-rc* kernel
2.fire off, or let the amanda crontab execute it, a run of amdump.
3.This will fail with an out of tape message unless the tape has more storage
than the total of the rest of the system.
  
Actual results:
Tar, regardless of the level of the backup its requested to do, will find
totally bugus sizes for even small, just one directory, disklist entries.

For instance, a du -h /GenesAmandaHelper-0.6 will report that there is 766 megs
of data in this subdir off the / system.  Tar however, apparently thinks there
is 136.2GB of data there to backup.  Where its getting this data I have NDI.

My amanda databases are so fubared by this now that it will take about a month
of running a 2.6.20.3 kernel to make them sane again.

Expected results:
A normal amanda backup

Additional info:
I do not think this is a filesystem problem, its all ext3, managed by LVM2 and
regardless of the kernel booted to, an 'ls -lc' to display the m or c times as
the convention might be, those times look absolutely sane to this user.  Thats
why I'm pointing the accusatory finger at tar.

I use vtapes so getting at this data is a piece of cake since a vtape is just
another dir on a separate hard drive.

My /usr/movies tree hasn't changed in several months as I haven't shot any
weddings lately.  It presently contains according to a du -h, a hair over 8.1GB
of data.  From one of these backups done under a 2.6.21-rc* kernel, here is an
ls -l of that particular file as it exists as a level 1 under these conditions:
-rw------- 1 amanda disk 7624687616 Mar 12 00:43 00001.coyote._usr_movies.1
Not quite 8.1GB but waaaayyyyy too big when it really should be just a list of
files since nothing has been changed recently enough to knock any dust off it.

That same file, with the kernel being 2.6.20.3-rsdl-03.30 or any other earlier
kernel will be as shown by this ls -lR of the Dailys dir:
[root@coyote Dailys]# ls -lR|grep movies.1
-rw------- 1 amanda disk         15 Mar 12 00:43 00001-coyote._usr_movies.1
-rw------- 1 amanda disk 7624687616 Mar 12 00:43 00001.coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar  3 02:03 00040-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar  3 02:03 00040.coyote._usr_movies.1
-rw------- 1 amanda disk         15 Nov 22 11:14 00003-coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar  5 01:45 00026-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar  5 01:45 00026.coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar  6 01:15 00027-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar  6 01:15 00027.coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar  7 01:52 00027-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar  7 01:52 00027.coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar  8 02:18 00025-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar  8 02:18 00025.coyote._usr_movies.1
-rw------- 1 amanda disk         10 Mar 10 03:27 00028-coyote._usr_movies.1
-rw------- 1 amanda disk      65536 Mar 10 03:27 00028.coyote._usr_movies.1
-rw-------  1 amanda disk         10 Mar 11 01:02 00026-coyote._usr_movies.1
-rw-------  1 amanda disk      65536 Mar 11 01:02 00026.coyote._usr_movies.1

So you can see what it is that is the problem, all of those should have been as
the 65k examples show.  Nothing but a file listing, the directry's contents have
not changed.  And no, I didn't know there was a Nov dated one there, something
is apparently wrong with the label headers on that particular vtape.

I'd like to get up on a soapbox and preach for a stable api and return values
system for tar, but sadly I know that is never going to happen.