Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Aug 1998 22:06:03 +0200
From:      Stefan Eggers <seggers@semyam.dinoco.de>
To:        zhihuizhang <bf20761@binghamton.edu>
Cc:        hackers <freebsd-hackers@FreeBSD.ORG>, seggers@semyam.dinoco.de
Subject:   Re: FFS questions 
Message-ID:  <199808272006.WAA02606@semyam.dinoco.de>
In-Reply-To: Your message of "Thu, 27 Aug 1998 12:20:14 EDT." <Pine.SOL.L3.93.980827120824.10706A-100000@bingsun1> 

next in thread | previous in thread | raw e-mail | index | archive | help
> The comment says it is the number of cylinders per *cycle* in position
> table.  What does the "cycle" mean?   Basically the position table is

That I don't know.  My guess would be the number of cylinders we can
seek during one rotation.

> transfer request for exactly that block.  But how can we measure the
> time it takes CPU (time-sharing by processes) to service an interrupt
> and initiate a new I/O?  Is the disk always moving around at constant

As I understand it one just experiments and finds out this way.

> and initiate a new I/O?  Is the disk always moving around at constant
> speed? When does the disk generate an interrupt? After it finish DMA a
> block or a sequence of contiguous blocks specified by the CPU's request?

As the rotational delay table is not used anymore these questions are
of no importance nowadays.  One has to rely on the drive being intel-
ligent enough to do the right thing nowadays.  With varying number of
sectors in different zones which one might not even know the para-
meters of it's asking a bit much to optimize for that in the OS.  And
then one still has to take into account caches, too.

>From the article on disk subsystem performance in /usr/share/doc I
conclude at that time there were already intelligent drives as we know
them now for IDE and SCSI.  They just present as a logical view of
what might be very different physically.

The drive itself decides how it orders the blocks, how to access them
and so on.  It is free to vary the the rotational speed at will or
with a similar effect to vary the data rate to get more sectors on the
outer cylinders.  On such a drive one can't assume anything about the
physical characteristics.  If one is lucky one can measure some things
and take advantage of them, of course.

The other mentioned type is a Fujitsu drive which sounds pretty much
like a dump MFM or RLL drive of that time.  A certain number of
cylinders, a number of heads and a fixed number of sectors per track.
I didn't read anything about tricks with varying the speed or data
rate at that time for such drives.  For these things like the rotation
block lists were invented.

If these drives were similar to the ones used in PCs the part which
does the interrupting is on the controller, not the drive.  I'd expect
it to send one when a command has completed - whatever the command
was.  A multiblock transfer - if supported by the controller - better
should do the same but even if not one can ignore the extra ones quite
easily.

Stefan.
-- 
Stefan Eggers                 Lu4 yao2 zhi1 ma3 li4,
Max-Slevogt-Str. 1            ri4 jiu3 jian4 ren2 xin1.
51109 Koeln
Federal Republic of Germany

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808272006.WAA02606>