*BSD News Article 19647


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!cs.utexas.edu!uunet!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark
From: mark@roissy.umd.edu (Mark Sienkiewicz)
Newsgroups: comp.os.386bsd.development
Subject: Re: Hard disk geometry translation (was V86 mode ...)
Date: 17 Aug 1993 21:48:03 GMT
Organization: University of Maryland
Lines: 59
Message-ID: <24rjmj$f11@umd5.umd.edu>
References: <24cc1hINNo8@kralizec.zeta.org.au> <CBo9C6.9ED@sugar.neosoft.com> <24gt3e$gg7@klaava.Helsinki.FI>
NNTP-Posting-Host: roissy.umd.edu

In article <24gt3e$gg7@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
>
> - it's easier.  'nuff said.  The "drive translation problem" subject
>   has never even come up in the linux camp as far as I know, but I seem
>   to see it every now and then in the 386bsd groups. 

You can't argue with that.

> - less problems with sharing the disk with other systems: the partition
>   table makes more sense if everybody agrees on the layout of the disk. 

or that...  Of course, I don't run any other OS on my machine, so this
doesn't bother me. :)

[ Ok, I asked for it :) - everybody send me mail telling me if you run 
other systems on your machine.  List which ones you use, and count NetBSD
and FreeBSD as *two* if you have two partitions for them. If I get more than
10 replies, I'll post a summary. ]

> - I personally think the "translation overhead" mentioned by some folks
>   as a source of inefficiency for the filesystems (either due to the
>   controller getting slower due to translation or due to the fs not
>   knowing about the real geometry) is mostly a load of bull-sh*t.  It
>   may have made sense 10-20 years ago, but I doubt the FFS disk
>   geometry optimizations are really worth it these days with
>   controllers that do sector mapping etc (the BSD 4kB blocks are
>   probably a *much* larger win when compared to linux' 1kB blocks). 

It seems to me just the opposite:  assuming the *wrong* physical geometry
could be as bad (or maybe worse) than not knowing about the geometry at all.  

I'd be real interested in hard data that sheds some light on this issue,
one way or the other.

> - parly the same as the above: new drives usually have a variable
>   number of sectors anyway in reality, so trying to use a "native
>   mapping" is definitely not worth it.  Let the hardware sort it out:
>   no need to worry unnecessarily on a software level.  Not to mention
>   the fact that it's ugly in the extreme that the filesystem should
>   need to know anything about the geometry in the first place. 

Rather than abandoning knowledge of the geometry, we need a filesystem that
knows about a variable number of sectors/track.  The problem with this
is finding out what the physical geometry is.  I recently acquired some
disks like this and the vendor's tech support line *knew* what the
geometry was, but didn't *want* to tell me.  "It's really complicated".
Yeah, right. :(

Of course, "_need_ to worry" is a different story.  Reality tells us that
many systems work just fine without this knowledge.  You can install a 
BSD FFS by picking the parameters out of the air, and it will still work.
Many of us don't suffer much if the disk throughput is a little slower
than it could be.

>Personal opinions, not backed by numbers..  Flame me all you dare,

Hmm?  Not a flame, just a different point of view.

Mark S.