SUMMARY: newfs fails with write error

From: Carlo Tiana (carlo@white.stanford.edu)
Date: Wed Oct 23 1991 - 00:53:44 CDT


I recently posted a query regarding newfs failing on on a Micropolis 1355
disk partitioned to be 1 big partition. I got a lot of replies, that raised
some interesting points. Unfortunately, I did not get to use any of them; I
hung the disk off of a different machine (a Sparc 2, it used to be on a
4/110) and I could not replicate the failure - ie newfs worked as
advertised. This adds to the puzzle, though my disk is now being useful,
the original aim. The original posting is at the bottom of this message.
Here follow ideas, suggestions and thanks.

-when something like this fails, check the console/messages to see if they
 give any more useful explanations than the error message. This should be
 obvious, but I hadn't done so (as it turns out, there were none).

- 4.1.1 doesn't seem to be very happy with non-default -i values

-check the format.dat file in case it got corrupted or is just wrong

-perhaps label it with one cylinder less.

-try running format/is the disk formatted (we all make mistakes...); well,
 the disk was formatted, but I think I would have reformatted it if I had
 not been successful by chance.

-check the SCSI id of the disk. This is a funny one; the disk has no
 obvious way to set the SCSI id. In addition, in the same enclosure there's
 also a 1/4" tape drive, presumably with its own SCSI id. I looked through
 the documentation I have, and found something pertaining to a different
 type of disk from Sun, which instructs one to do some magic on the order
 in which disks sit on the SCSI daisychain in order to change their IDs. I
 tried this, without success. Does anyone know how to do this? I need to
 figure this out soon, and if I get enough info, I will make a followup
 posting.

- I got in a discussion with a couple of you on the merits or otherwise of
 using 'c' as the partition for the whole disk (I had made 'g' the same
 size as 'c' and was going to use 'g'). I don't have any firm facts as to
 whether one can or should just use 'c' if the disk has only one partition.
 I had chosen to use 'g' because I felt that was where '/usr'-type stuff
 is usually kept. My feeling was that perhaps the reasons for this are just
 historical. But others are using 'c', I assume with no problem.
 Someone else said on the other hand that his "experience indicates that it
 would be a mistake to rely on only a c partition. Having the g partition
 match the c was the right thing to do". The verdict is still out...

Thanks to all:

From: kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
From: "Anthony A. Datri" <datri@concave.convex.com>
From: dal@gcm.com (Dan Lorenzini)
From: erueg@cfgauss.uni-math.gwdg.de (Eckhard Rueggeberg)
From: mcostel@kaman.com (Mark Costello)
From: keith@odi.com
From: vasey@mcc.com (Ron Vasey)

Carlo.

--------
Here is the original message:
>
> I am tring to newfs a SCSI disk with just one partition equal to
> the whole disk. The disk is a:
> Current Disk = sd0: <Micropolis 1355 cyl 1018 alt 2 hd 8 sec 34>
> and it hangs off a 4/110 running 4.1.
> The command I issue is:
> newfs -v -m 0 -i 8192 /dev/rsd0g
> and I get the following error:
> write error: 276895
> wtfs: I/O error

> If I try newfs with -N thus:
> newfs -Nv -m 0 -i 8192 /dev/rsd0g
> I get the usual:
> setting optimization for space with minfree less than 10
> mkfs -N /dev/rsd0g 276896 34 8 8192 1024 16 0 60 8192 s 0 -1 8
> /dev/rsd0g: 276896 sectors in 1018 cylinders of 8 tracks, 34 sectors
> 141.8MB in 64 cyl groups (16 c/g, 2.23MB/g, 256 i/g)
> super-block backups (for fsck -b #) at:
> 32, 4432, 8832, 13232, 17632, 22032, 26432, 30832, 34848,
> 39248, 43648, 48048, 52448, 56848, 61248, 65648, 69664, 74064,
> 78464, 82864, 87264, 91664, 96064, 100464, 104480, 108880, 113280,
> 117680, 122080, 126480, 130880, 135280, 139296, 143696, 148096, 152496,
> 156896, 161296, 165696, 170096, 174112, 178512, 182912, 187> 312, 191712,
> 196112, 200512, 204912, 208928, 213328, 217728, 222128, 226528, 230928,
> 235328, 239728, 243744, 248144, 252544, 256944, 261344, 265744, 270144,
> 274544,

> Any ideas?



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:17 CDT