On Wednesday 09 January 2002 03:02 am, Gene Heskett wrote: >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?
Next followup: I played around with it till I gave up, I can access the unit with mtx to do the changer stuff, mt to do the rewinds, and dd to extract the tape headers, and do it 100% of the time. Switch to scanning the rack with amcheck, and its an i/o error 99% of the time _if_ the currently loaded slot isn't zero. I note from the drive leds that amcheck does two reads with a rewind between them before ejecting that tape, but that it reports the error to the screen after the _first_ read. It doesn't always report the correct slot if the rack has been moved by hand attempting to place the correct tape in the current, first one it will read, slot. The current rack position is available via the mtx command, so the info is available to amanda. I just stepped back into the 2.4.2 sources I'd been running, made myself root and re-installed it. amcheck worked properly the first time. So it appears that for me at least, with my Seagate 4586np changer, that 2.4.3b2 is indeed broken. -- Cheers, gene
