Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!doc.ic.ac.uk!uknet!mcsun!Germany.EU.net!news From: bs@Germany.EU.net (Bernard Steiner) Newsgroups: comp.os.386bsd.development Subject: Re: Hard disk geometry translation (was V86 mode ...) Date: 19 Aug 1993 11:31:25 +0200 Organization: EUnet Deutschland GmbH, Dortmund, Germany Lines: 20 Distribution: world Message-ID: <24vh9d$d1r@Germany.EU.net> References: <107725@hydra.gatech.EDU> <1993Aug9.224939.19834@fcom.cc.utah.edu> <24cc1hINNo8@kralizec.zeta.org.au> <CBo9C6.9ED@sugar.neosoft.com> <24gt3e$gg7@klaava.Helsinki.FI> <PCG.93Aug18183353@decb.aber.ac.uk> NNTP-Posting-Host: qwerty.germany.eu.net In article <PCG.93Aug18183353@decb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes: |> >>> On 13 Aug 1993 23:21:02 +0300, torvalds@klaava.Helsinki.FI (Linus |> >>> Torvalds) said: |> Linus> - I personally think the "translation overhead" mentioned by some folks |> Linus> as a source of inefficiency for the filesystems (either due to the |> Linus> controller getting slower due to translation or due to the fs not |> Linus> knowing about the real geometry) is mostly a load of bull-sh*t. It |> I tend to agree with this. In practice the biggset, and by far, wins, |> are from keeping blocks physically clustered, and from issuing |> multisector reads and writes for sequential access. Though I like the idea of the system doing its own optimization, there is a at least another problem: There are disks out there that have a variable number of sectors per track, depending on the cylinder you are on. Unless the disklabel stuff is actually re-written to cope with this, physical addresses don't make much sense. -Bernard