Disk problems

[Andrew Kelly]

I have a fairly new installation of Ubutu 5.04, on an old ex-Windows box 
(all trace of Windows has been scrubbed out). It has been working OK, 
but I've recently added a couple of big new drives to it and have been 
trying to backup to one of them (using tar) but have problems, as 
described below.

The system disk (/dev/hda1) is only 4.5G, as you can see below. I'm 
trying to backup to a file on /var/backups (/dev/hdc3 = 110G). As you 
can see below, the other volumes have not very much on them.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             4.5G  1.5G  2.9G  34% /
tmpfs                 253M     0  253M   0% /dev/shm
/dev/hdb2             4.0G   43M  3.7G   2% /home
/dev/hdb3             4.0G   41M  3.7G   2% /var/www
/dev/hdb4             103G   33M   98G   1% /var/mail
/dev/hdc3             110G  165M  105G   1% /var/backups
/dev/hdc5             335M   31K  317M   1% /tmp
/dev/hdc6             335M   13K  317M   1% /var/tmp
/dev/hdc7             327M  274K  310M   1% /var/spool
/dev                  4.5G  1.5G  2.9G  34% /.dev
none                  5.0M  2.8M  2.3M  56% /dev

The backup script looks like this:

$ cat do_backup
#!/bin/sh
#
# backup script
#
tar cvpzf /var/backups/backup.tgz / --exclude=/var/backups 
--exclude=/proc --exclude=/lost+found --exclude=/mnt --exclude=/sys

The backup runs for a fair while successfully, then hangs when it gets 
to the file 
/usr/share/doc/python2.4-opengl/doc/xhtml/glutShowWindow.3GLUT.xml.gz, 
which, according to indexes I found on the web should be a small (1k or 
2k) file.

However, on my disk (which, remember, is only 4.5G big) this file is 65G 
(!) as you can see:

$ ls -lh 
/usr/share/doc/python2.4-opengl/doc/xhtml/glutShowWindow.3GLUT.xml.gz 
-rw-r--r--  1 root root 65G 2003-10-26 11:40 
/usr/share/doc/python2.4-opengl/doc/xhtml/glutShowWindow.3GLUT.xml.gz

Clearly, there is something wrong here...

My first thought was to run e2fsck to check the disk, but it said the 
disk was mounted and warned against proceeding. So after a bit of 
research I ended up setting the maximum mount count to 1 and did a 
restart. Sure enough, the disk was checked when the system rebooted. The 
check was OK though, and I still have the problem.

Here's the start of the output of dumpe2fs:

$ dumpe2fs /dev/hda1

dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          04c092d5-c871-4bfe-8bd6-5d62f2d45954
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery 
sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              595552
Block count:              1190810
Reserved block count:     59540
Free blocks:              795602
Free inodes:              517449
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16096
Inode blocks per group:   503
Last mount time:          Wed Sep  7 13:03:38 2005
Last write time:          Wed Sep  7 13:03:38 2005
Mount count:              1
Maximum mount count:      1
Last checked:             Wed Sep  7 13:03:37 2005
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Journal backup:           inode blocks

Is there a more thorough check/repair I can do?
If so, how?
Does anyone have any other suggestions?