brandon@tdi2.UUCP (Brandon Allbery) (12/25/86)
Expires: Quoted from <145@piaget.UUCP> ["Re: fsck says "size check". What to do?"], by jc@piaget.UUCP (John Cornelius)... +--------------- | 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 | | 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. | | The variable names given here are System V variable names however | BSD has synonymous variables. +--------------- I have already replied to this, since I've had to deal with this exact problem before. However, I'll summarize to save the net some confusion. The Pixel/80 does NOT run 4.2BSD. It runs Unisoft System III with symlinks and 4.2BSD utilities added; no big directory entries, no sockets, and the "mkdir" and "rmdir" system calls are extant but broken and are blocked in the operating system. There's no paging or multiple swap partitions, either. This curious mixture appears to be the cause of the problem. For some reason, when a disk on the Pixel/80 gets full, the fs.s_fsize and fs.s_isize entries (and ONLY those entries, as far as I can tell) get trashed. Since I knew the correct size of the /dev/win0g partition, I used adb (fsdb wasn't there) to patch the raw disk partition and was able to mount read-only and tar off the files, then mkfs and restore the files. (As I said, ``as far as I can tell.'' Fsck didn't complain about it, but I didn't want to risk it.) ----- I have my own questions about file systems. sVr2.2. One time I accidentally mounted a disk partition which was being used as a UNIFY raw database. I was able to umount it before it got trashed (singleuser doesn't sync, apparently), but I noted later (while looking up superblock stuff so I could fix the Pixel hard disk mentioned above) that sVr2 has a magic number in the superblock. The data in the UNIFY database header looks nothing like the magic number. My question: if there is a magic number there, why doesn't mount() look for it and reject file systems with bad magic numbers? And why doesn't fsck look for it as well and report a non-UNIX partition? (I got stopped by the same "size check" message on that partition, later.) This was on a Plexus P/60, then running "Plexus sys5.2 1.4 M". (`M' is for the 68000 version, as opposed to the `S' 68020 version.) Was this just not ported correctly, or is this true of all sVr2.2 ports? [Note: Plexus buys directly from AT&T; it's NOT Unisoft or Xenix.] ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210