info-vax@ucbvax.ARPA (08/09/85)
From: <PMANERA%NYBVX1.BITNET@WISCVM.ARPA> A few of you asked for me to report my findings and after a real horror show, this was what it boiled down to: the XQP driver. Apparently, not a "few" bugs have been discovered in it since 4.0. 4.1+ has a lot of fixes in, but still a few are remaining. My particular problem occurred because of a horribly fragmented disk. I didn't get the full story on this, but suffice it to say that the driver "leaks" quite a bit of diskquota when it has to create lots and lots of file headers. After all of the suggestions, I finally decided to test my own theory. We use CCA emacs a lot here, and one of our students was the first to notice that he could not account for about 400 blocks of quota. CCA's emacs maintains files in its own tree for crash recovery for every user. The user can't see them, but feels its impact. But this particular user knew that, and still couldn't find the 400 blocks. DIR/SIZ found nothing, so I decided to move the emacs tree to a disk on which I had not enabled diskquotas. I then proceeded to delete the entire emacs tree from its original drive. When I was done (including the [000000]EMACS.DIR entry, I checked DISKQUOTA - 1936 blocks used. DIR/SIZ/BY found nothing, and I got confused. It was now around 1a.m. REBUILD, ANAL/DIS/REP, kicking, nothing helped. I decided to do a refresh. Backed up the drive, INITed it, created QUOTA.SYS, rebuilt it, and wound up with around 2500 blocks owned by an assortment of UIC's. Now it's 4a.m.! Because I was using some qualifiers on my INIT (/DIR=500/HEAD=10000/CLUS=1), I decided to do it straight, with no qualifiers, and damn if it wasn't perfect after the REBUILD. Tried it again with qualifiers, same funny users had files out there. (Remember, this is right after an INIT!!!) Not sure how, but I finally got my qualifiers to come up clean. It's around 6 in the morning now, and I've been in the Center since 9 the morning before. I start my restore and get thousands of error messages for my efforts. About 90 files were allocated to the same virtual address on the disk. And, of course, you get one error message for each BLOCK!!!! that's doubly allocated. Not to leave us hanging, DEC has given us a procedure for MULTALLOC in the System Messages and Recovery Procedures. It works, if a bit manual in its usage. At 9:30 that second morning, I had most of the stuff fixed. Some files were lost, so I went back to the BACKUP I had done the night before. Unfortunatly, that backup saveset copied the bad structure, and I was almost dead tired, so those files had to come from earlier, none-corrupt savesets. Bottom line? If you've got (or think you might have) a fairly fragmented pack, be careful! I wish I could tell you what, exactly, to do, but I'm afraid I lost track of what I did - right or wrong - that night. Maybe someone can shed some light. Peter Manera - NYU