Pixel/80 trashed fs

[Brandon Allbery]

Expires:


Quoted from <145 at piaget.UUCP> ["Re: fsck says "size check". What to do?"], by jc at piaget.UUCP (John Cornelius)...
+---------------
| In article <718 at cooper.UUCP> chris at 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 at Case
7350 Corporate Blvd.	       INTERNET: ncoast!allbery%Case.CSNET at relay.CS.NET
Mentor, Ohio 44060		  PHONE: +1 216 255 1080 (home) +1 216 974 9210