Very many thanks for the swift and helpful responses from
Jonathan.Buchanan_at_ska.com
bernards_at_ecn.nl
gk_at_gkws.edvz.tuwien.ac.at
The story.
These files were Ultrix executables that the user tried to strip using
OSF/1 V3.0 strip. I don't understand the properties of these files but
dump and GNU tar both try to copy huge amounts of Mbytes. (It was the
6 Gbyte DLT unexpectly filling up brought this to my attention).
I have repeated the process and created more 412Gbyte files on an
otherwise junk partition and it appears to OK to just delete these
files.
So I have used GNU tar to backup the partition excluding these files.
I will delete the rouge files and restore from a backup done before
the strip.
I had noticed that backups were failing because of lack of semaphores
on this partition which I thought was because the user had rebuilt the
kernel on this machine to support the Sound Card. It was only when I
installed OSF/1 3.2C with an increased SEMMNS that the problem came to
light.
Stip on 3.2C fails with an I/O error and produces a zero length
temporary file so we are safe against this problem in the future.
(I was amused the the DEC support person I spoke to had not even heard
of GNU !! )
Many thanks to you all.
Tim.
Original question.
>
> Hi all,
>
> On one of our alphas (400-2/233 OSF/1 V3.2C ) has developed a problem
> with the UFS filesystem on the g partition on its internal disk
>
> The partition table
> # size offset fstype [fsize bsize cpg]
> a: 262144 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 328*)
> b: 1048576 262144 unused 1024 8192 # (Cyl. 328*- 1642*)
> c: 2050860 0 unused 1024 8192 # (Cyl. 0 - 2569)
> d: 0 0 unused 1024 8192 # (Cyl. 0 - -1)
> e: 0 0 unused 1024 8192 # (Cyl. 0 - -1)
> f: 0 0 unused 1024 8192 # (Cyl. 0 - -1)
> g: 740140 1310720 4.2BSD 1024 8192 16 # (Cyl. 1642*- 2569*)
> h: 0 0 unused 1024 8192 # (Cyl. 0 - -1)
>
> du and df reports appear OK
>
> # du -s -k
> 202382 .
> # df -k .
> Filesystem 1024-blocks Used Avail Capacity Mounted on
> /dev/rz0g 357989 202382 119808 63% /local/data
>
> But dump estimates is huge breaking our nightly backups
>
> # dump 0f /mnt/tmp/data/shelley.dmp /dev/rrz0g
> dump: Dumping from host shelley.dra.hmg.gb
> dump: Date of this level 0 dump: Thu Nov 16 09:53:02 1995 GMT
> dump: Date of last level dump: the start of the epoch
> dump: Dumping /dev/rrz0g (/local/data) to /mnt/tmp/data/shelley.dmp
> dump: Mapping (Pass I) [regular files]
> dump: Mapping (Pass II) [directories]
> dump: Estimate: 15145784 tape blocks on 0.00 volume(s)
> dump: Dumping (Pass III) [directories]
> dump: 0.00% done -- finished in 25:14
>
> I have tracked down the problem to one directory where ls -l incorrectly
> report 412Gbyte files !!
>
> # ls -l
> total 4928
> -rwxr-xr-x 1 shannon users 412316954624 Oct 6 10:05 HCode
> -rwxr-xr-x 1 shannon users 412316983296 Oct 6 10:05 HCompV
> -rwxr-xr-x 1 shannon users 412316954624 Oct 6 10:05 HCopy
> -rwxr-xr-x 1 shannon users 412317016064 Oct 6 10:05 HERest
> -rwxr-xr-x 1 shannon users 412317028352 Oct 6 10:05 HHEd
> ...
>
> I have tried umounting the disk and doing an fsck -o /dev/rrz0g but it
> passed cleanly.
>
> Any Suggestion on how to recover or should I newfs the partition and
> restore from last weeks backup?
>
> Thanks for any suggestion
>
> Tim.
>
Received on Thu Nov 16 1995 - 15:49:28 NZDT