chris@cooper.UUCP (Chris Lent ) (12/14/86)
Here's an interesting one: A Pixel-80 system (BSD 4.2 system with "PIXEL" slapped on top :-), I have some contact with went through the following: A. File system filled up on /usr with "No space on dev 00/06" messages. B. A couple of big files removed. C. df messages which say a couple of thousand free blocks but still 100.0% used?!? D. When they re-boot they get the message: size check: fsize 1701978227 isize 22764 But when the file system (/usr by the way) is mounted all the files are accessible. I think they're darn lucky and should back up the whole file system using a file-by-file backup like cpio or tar, do an mkfs, and then restore the whole thing, but they seem doubtful since they can do everything they want too. Is their any other way to repair this damage without all the work involved? P.S. What the heck does "size check" mean anyway? Something like superblock has a silly size for the filesytem and you better think twice about mounting this filesystem or your free list make no sense? -- Chris Lent ihnp4!allegra!phri!cooper!chris
jc@piaget.UUCP (John Cornelius) (12/18/86)
In article <718@cooper.UUCP> chris@cooper.UUCP (Chris Lent ) writes: >Here's an interesting one: > >A Pixel-80 system (BSD 4.2 system with "PIXEL" slapped on top :-), >I have some contact with went through the following: > > A. File system filled up on /usr with > "No space on dev 00/06" messages. > > B. A couple of big files removed. > C. df messages which say a couple of thousand free blocks > but still 100.0% used?!? > > D. When they re-boot they get the message: > >size check: fsize 1701978227 isize 22764 > >But when the file system (/usr by the way) is mounted all the >files are accessible. > >Is their any other way to repair this damage without all the work >involved? I believe that BSD provides alternate superblocks, the first one being (I think) at block number 32. Fsck can be coerced to repair the damage by using one of the alternative superblocks. They are assigned at the time newfs is run to create the file system. Otherwise, if they have fsdb, they can repair the filesys.s_fsize variable in the superblock. If they REALLY know what they're doing they might even be able to fix the problem with the program debugger. > >P.S. What the heck does "size check" mean anyway? Something like The variable filesys.s_fsize in the superblock is unreasonable. As much as we'd like to have an 871 gigabyte file system, we don't and fsck knows it. The variable names given here are System V variable names however BSD has synonymous variables. -- John Cornelius (...!sdcsvax!piaget!jc)