Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!pcserver2!kdenning From: kdenning@pcserver2.naitc.com (Karl Denninger) Newsgroups: comp.sys.mips Subject: Re: Miscellaneous questions Summary: Disk additions and other fun things Keywords: Diskspace, newfs.ffs, mount Message-ID: <1991Jan10.223640.12520@pcserver2.naitc.com> Date: 10 Jan 91 22:36:40 GMT References: <1991Jan7.160027.5883@athena.mit.edu> <439@spim.mips.COM> Organization: AC Nielsen, Bannockburn IL USA Lines: 84 In article <439@spim.mips.COM> rogerk@MIPS.com (Roger B.A. Klorese) writes: >In article <1991Jan7.160027.5883@athena.mit.edu> glee@athena.mit.edu (Gilbert Huppert) writes: >>Question #1: How do I access the full potential of the disk? > >Well, it's not clear what the full capacity really is, Gil. When disk >marketeers talk about megabytes, they talk about thousand-bytes, not >1024-bytes, so there's a loss right there. Additionally, the FFS structure, >inode table, superblocks, etc. do eat a good bit of space. Yep. I have found that about 10% of the disk area is eaten internally on ffs partitions. This is true across systems; Suns do this too. However, I'm happy to pay the price for the better performance and things like long filenames -- two things I can't have on System V filesystems from anyone... even those vendors that do support it. I'll take the ffs anyday. >>Question #2: Is there anyway the minimize the reserved disk overhead? > >Actually, the 10% is not reserved to minimize crashes, but because the >cylinder-block allocation algorithm gets messy on very full disks. You >can tune the threshhold for a partition down from 10% with /etc/tunefs.ffs: > > /etc/tunefs.ffs -m 3 /dev/rdsk/isc0d1s2 > >would drop it to 3%. (You would need to do this on an unmounted filesystem, >or tune, unmount, and remount, for it to be seen.) Be careful doing that however -- it MAY cause somewhat serious performance problems when the disk gets nearly full! >>Question #3: Any ideas why I might not be able to mount a free filesystem? > >Be certain that no partitions in use overlap your problem partition. That will certainly cause problems :-) One other thing I have noticed: Unsupported disks are no problem at all on the MIPS systems. You just have to do some strange things in the standalone formatter, and make the filesystems by hand (ie: use mkfs.ffs, not newfs.ffs). The basic trick is to enter all the information (cylinders, heads/cylinder, etc) -- the low level format is unnecessary, as is the bad-block scan (assuming you know that the drive has correctly spared the bad blocks internally). The scan isn't a bad idea to run if you have any questions.... I have no idea if this would work for bootable system disks, but I can't see why not if you follow all the other (necessary) rules about partition layout and the like. I have done two drives with this method, and find that I get both excellent performance AND allocation the way I want it, when I want it. Neither one is "officially" supported (Maxtor 8760Ss) however they work real well. One trick -- specify a few (20 or so) blocks less than the actual partition size when you do the "mkfs.ffs". For some reason unknown to me, if I specify the exact block count the system refuses to initialize the partition.... even though there IS enough space on the volume in the partition where I'm trying to put the new filesystem. It complains about not being able to write the last couple of blocks and quits.... Also, being truthful (ie: supplying the information) about sectors/track and the like seems to help I/O performance somewhat. One final warning -- in the 3260 cabinets, they warn you to jumper secondary and beyond drives to power up on a START command. Most SCSI devices don't ship in this configuration; check the jumpers before you install! I have no idea how serious this problem really is, but 'tis better to be nice to the power supply :-) Enjoy! 700MB disks currently run about $2k each, 1.2GB drives are a little more. Quite reasonable overall... -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.