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.