Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!gatech!news.mathworks.com!fu-berlin.de!cs.tu-berlin.de!uni-erlangen.de!news.tu-chemnitz.de!News.HTWM.De!news.HRZ.HAB-Weimar.DE!news.uni-jena.de!news.uni-leipzig.de!news1.urz.tu-dresden.de!irz401!uriah.heep!news
From: j@uriah.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: How do I add a hard disk!?
Date: 14 Apr 1996 18:33:48 GMT
Organization: Private FreeBSD site, Dresden
Lines: 128
Message-ID: <4krgec$7h3@uriah.heep.sax.de>
References: <316AD77F.5C37@quickweb.com> <4kms6f$f8c@uriah.heep.sax.de>
<4kq7sq$56v@mark.ucdavis.edu>
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
NNTP-Posting-Host: localhost.heep.sax.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 0.9.6
samorosh@marmot.cs.ucdavis.edu (Steven Samorodin) writes:
> I don't really know where to go at this point, at first I thought
>about making a disktab entry, but I just don't have the information to
>do that and the posts here seem to indicate that sysinstall is a much
>better route to go anyway, so I tried that.
Well, you actually have the information for a disktab entry. It's
printed out at boot time:
sd1(bt0:1:0): Direct-Access 2049MB (4197405 512 byte sectors)
^^^^^^^
That's the only information you really need. You have to enter it as
the su# capability. Everything else can either be guessed or omitted.
The nc#, ns#, and nt# capabilities must be there, but they are allowed
to be bogus as long as su# is correct (without ill side-effects), so
you can always enter your birthday there. :)
> I have a 1GB Seagate SCSI drive that I want to add so I tried
>using the Custom Installation and modifying the partition and label.
There used to be some hidden bogons when using sysinstall for it. :-(
> When I choose
>N for NewFS it shows the following options
>newfs -b 8192 -f 2048 -u 3907
>
>reading the man page I found out that -b stands for block-size, I can handle
>this one though I don't think that really want 8k blocks, aren't 512, 1024, or
>2048bytes the standard block sizes???
You want 8 KB blocks, unless you're setting up a news server. Without
going into much of the details that can be found in the ``Daemon
book'', or in /usr/share/doc/smm/05.fastfs/paper.ascii.gz, larger
blocks mean less overhead, but more waste of space.
These are _file system blocks_ (``clusters'' in the FAT file system
terminology), not _disk_ blocks. You cannot (easily) change the
latter...
>-f stands for the frag-size. What is a frag-size? The man page has amazing
See also in the paper above. Basically, a good choice is to have
the fragment size 1/8th of the block size.
>-u stands for sectors/track.
Largely irrelevant. I wouldn't even touch this number.
Boys, your (not only your, Steven) _biggest misunderstanding_ is: the
physical geometry of modern drives is totally irrelevant for anything.
Put your drive manual into the shredder, you're only confused by
reading it! (Well, don't, perhaps you need the jumper settings some
day. :)
There's one geometry setting that is interesting for the boot process,
and for co-existance with other systems on the same drive: the BIOS
geometry, i.e. how the BIOS believes the disk were divided in
cylinders and heads. This one is only important since the BIOS still
thinks in C/H/S for every operation that is handled via its defined
API, the interrupt 0x13 functions. Since the boot blocks pick the
C/H/S values directly off your fdisk table and feed this value
unverified and unchanged into interrupt 0x13, you still have to care
for such ancient crap like cylinders...
Once the kernel is loaded, all cylinders and heads and sectors are
away, the Unix system interface does everything in terms of disk
blocks (usually à 512 bytes), and if you're lucky to own a SCSI disk,
these disk blocks can be passed directly down to the device. (IDE
interfaces convert to some bogus C/H/S value temporarily, since this
is the traditional interface for them. Any modern disk simply picks
up the passed C/H/S, recomputes the block number internally, and
locates this block somewhere on the disk -- much similar to a SCSI
drive.)
Again: your physical drive geometry (which normally can't even be
expressed as a uniform number of sectors per track) is absolutely
irrelevant, and the only interesting logical geometry is the one the
BIOS is using.
>: > e: 666545 0 4.2BSD 0 0 0 # (Cyl. 0 -
>: 1024 8192
>:
>: should be there. You can do all this with `disklabel -e'.
>:
>I am not sure what the nit is?
It's the file system block and fragment size. You normally don't
specify it at `newfs' time, but rather at `disklabel' time. The
usual newfsing runs like
newfs /dev/rwd1s1e
or perhaps
newfs -d0 /dev/rwd1s1e
(might be more optimal for most modern drives).
>: After this (and after making the device nodes -- but you've done it):
>:
>When did I make the device nodes?
This was in the posting i've been answering. Until the `device file
system' (devfs) is operational, which does all these hairy things
automagically on your behalf, you ought to
cd /dev
./MAKEDEV wd1s1
(or something like this) in order to put the device nodes in place.
>Well, if you think you can help me please email me, I am not having
>much luck here myself. Thanks.
I didn't email since, until the proper tool is ready, i will repeat
myself over and over again in this group. Hopefully, this will avoid
more than 20 % of these questions. (They are all the same, btw., you
only need to browse via all articles containing `disklabel', and the
answers are also all about the same.)
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)