On Tuesday 08 January 2002 09:10 pm, you wrote:
>Hi folks.
>
>I just got through a day and a half of trying to find out why I
>couldn't do a backup, this after installing 2.4.3b2 over my
>2.4.2p2++++ install about the 3rd of Jan 2002.
>
>amcheck and df both kept saying my 40g drive was full, when the
>last time I checked it a week or so back it  was sitting at 14%
>full.  That was my clue that it probably was just one totally
>humungous file someplace, the question was where on a 40g drive?
>
>I wrote several one liners based on tree, and ls -lR, trying to
>see if it was amanda related, but it turns out I had to go
>looking by hand to find the drive space filler.
>
>I don't recall if I had noted the 'configdir/tapestatus' file as
>ever being anything but a zero length file before, but when I
> did an ls -l in the /usr/local/etc/amanda directory, it stuck
> out like a very long, badly swollen sore thumb as it had blown
> itself up to 30,367,168,256 bytes, aka 30 gigabytes!
>
>Humm, it was in one of the outputs of my searchs, here
>
>-rw-r--r--    1 amanda   amanda   30307168256 Jan  8 08:30 \
>tapestatus (darned kmail, wraps lines)
>
>It took rm -f about 3 minutes to delete it, and the drive is now
>back to 18% full, so I'm a much happier camper that I was 10
>hours ago when I gave up and went to work.
>
>I had been fooling around, trying to make the "emubarcode"
> option work, but gave up as it, even if defined but = 0, gave
> me database format errors, so apparently thats not an option
> one can turn on and off at will.  I relate this as it may have
> something to do with a 30 gigabyte tapestatus file.
>
>But I will let the resident experts digest this one, and tell me
>if its safe to continue before I remove the #'s from the first
>character position of each amanda related line in my crontab.
>
>Trying to recover from a full drive when even e2fsck can't do
>anything but puke all over itself when it runs into a file that
>size isn't exactly my cup of tea.  While the filesystem may now
>handle files into the petabyte range as of kernel-2.4.13-8, I
>don't recall seeing anything about e2fsck also being so blessed.
>Can someone clarify that please?

Followup. I deletd the file, and its currently back up to about 
9k after a failed amdump.  It apparently scanned the rack looking 
for the next tape but didn't find it.  10 minutes after I'd 
gotten the email indicating it was still in the holding disk, I 
ran amcheck which found the tape just fine.

So I ran amflush, which is currently appearing to do the flush 
without showing any errors.

So, I guess the next question is why didn't amdump write the 
tape, when 10 minutes later, amflush has no problem doing it?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
98.3+% setiathome rank, not too shabby for a hillbilly

Reply via email to