From: Giovanni Navarrette (gio@uslink.net)
Date: Mon Aug 26 2002 - 11:22:04 EDT
Hey everyone:
I got a response that fixed my problem. It was to try running mkfs by hand
and specifying 64 tracks for the format instead of the 127 the system was
trying to use:
> bash-2.03# newfs -v -f 4096 /dev/rdsk/c0t112d0s3
> newfs: construct a new file system /dev/rdsk/c0t112d0s3: (y/n)? y
> mkfs -F ufs /dev/rdsk/c0t112d0s3 218322144 127 127 8192 4096 251 1 90 8192 -t 0 -1 8 127
^ ^
So I tried it with 64, and it worked better...
bash-2.03# mkfs -F ufs /dev/rdsk/c0t112d0s3 218322144 64 64 8192 4096 251 1 90 8192 -t 0 -1 8 64
mkfs: bad optimization value `-t' reset to `t' (time)
Warning: 2848 sector(s) in last cylinder unallocated
/dev/rdsk/c0t112d0s3: 218322144 sectors in 53302 cylinders of 64 tracks,
64 sectors
106602.6MB in 773 cyl groups (69 c/g, 138.00MB/g, 17408 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 282720, 565408, 848096, 1130784, 1413472, 1696160, 1978848, 2261536,
2544224, 2826912, 3109600, 3392288, 3674976, 3957664, 4240352, 4523040,
...,...,...
So 64 worked, no 'performance may be impaired' error. Now, what is the
best size to use for tracks? I'm guessing that 64 may be ok, but what
would be optimal? Will the system be hurt from setting this to 64, or
should I just use the default 127 tracks? Thoughts/suggestions? I'll be
putting up a summary for this one..., this is a nasty one.
Thanks for everyone's input. :) Have a g'day.
-
-------------------------------------
Giovanni Navarrette
USLink Internet Systems Administrator
e-Mail: gio@uslink.net
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:24:50 EDT