On Sun, 30 Jul 2000, Rogier Wolff wrote:
> Andre Hedrick wrote:
> >
> > | +------ LBA 0 top of platter.
> > | +----- LBA End top of platter.
> > |-----------------------------------
> > |
> > +--- axis of rotation.
> >
> > We do a C or inverted Q position loop, real basic stuff for prediction by
> > knowing the characteristic of the media in a documented way.
>
> Please excuse my rambling...
Did...
Do the same for me because I do not docs yet but understand their design
theroy.
> Now on a modern Linux machine, can the kernel improve a lot on disk
> access times?
Yes, as much as I find it painful to admit...
> One of the main problems is that in average use, there is just one or
> two threads reading stuff from the disk. The threads will be "blocked
> waiting for IO to complete" and issue their next IO request after they
> have the results of the current IO. So at most there will be just one
> or two requests in the disk queue that you can order either the right
> way around, or the wrong way around.
This device is unique because one, I will know discrete documented data
about the behavior of the media, the heads, and servo. By knowing the
head selection by the LBA range and which side of the media you are
working on actively, you can prevent the excess arm-swing and long throws
ate wrap-around points.
LBA-MAX/2 == half capacity or one side of platter == HCOSP
Define LBA 0 == Physical LBA 0 + Physical Track Sector Offset.
Define LBA MAX == Physical LBA 0 + Physical Track Sector Offset - 1.
PTSO is not known by me yet.
Thus we have three parts of the media to model.
Range 0 == PTSO - 1 (end of logical media)
Range 1 == HCOSP - (Range 0) + 1 (begining of logical media -> spindle)
Range 2 == HCOSP with Virt LBA 0(r2) + 1 defining start point.
This is messy.....
| +------ LBA 0 top of platter.
| +----- LBA End top of platter.
|00000000000000000000000000000000222
|-----------------------------------
|11111111111111111111111111111111111
|
+--- axis of rotation.
You never want to access 2's if you are in 0's until all '0's are done
or you are in 1's or there are no 1's in the queue.
All of this is based on the head sweep direction and the sync of position
of a plater in "ORBital Spin" with a moving center axis of rotation.
This is my defining term of ORBS and not Castlewood's.
Sector locations should be viewed in an elliptical rotating coord.
referrence frame, which must be mapped back to IRF of the device case.
Also the excentricity may vary based upon spin-ups; however, the nature of
rotational mechanics tends to force us into a stable state and position,
and now predictable access for optimizing for the 'vator can begin.
> Where it DOES make a difference doing things right, is in writing. We
> write-cache a lot of blocks. At the moment when we come into memory
Assume no WC, the 'vator will attempt to setup request to minimize the
problem of rev-slipping to maintain fundamentail ordering access.
> pressure or some time has elapsed, we start throwing data over the
> wall to the disk subsystem to write them to disk. If the disk
> subsystem could then indicate which blocks it can write also with VERY
> little overhead, then that would increase write speed significantly.
But WC returns the indication that data2disk happened, thus if you can
pre-order requests then you can effectively stream to cache. This will
prevent drive reordering 90% (wag number based upon cache hits) of the
time, which if the cache is full you get a busy-bit return and the
rescheduling begins.
> So, even when there isn't any memory pressure and no timeout has
> triggered, when you're writing block n, you should also write block
> n+1 if it happens to be dirty.
But then you need to go back and clear the n+1, correct?
Why not ram down a flush_cache_command?
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
PS: note it is late and my eyes do not focus well on goldstein or
french at this hour, much less my reading notes on orbital/celestrial
mechanics assuming n-body solutions.
Sheesh what a ramble.....ask me again in the morning......
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:31 EST