[Sluglug] new to the list

[Ignacio Solis]

* cerise at armory.com (cerise at armory.com) said:
> Owing to the uncertainty of where the head is over the disk at that point,
> one would try to cover as much of a rotation of the disk as possible with
> data which are frequently of use.  While it is possible that you will incur a
> full rotation around the disk to read data that you just passed, it is
> equally as likely that you'll be at the beginning of the data for the next
> file that you want.  As a result, it's reasonable to assume that there will
> be an average half rotation delay.
> 
> If you were to pack them all within the same pie slice of the disk, that gives
> a probability of arc-length-of-slice/circumference-of-disk that you'll be in
> the right region and 1-(arclength/circumference) that you aren't.  The cost
> for that probability is much greater than 1/2 a rotation.

What are you talking about? You suddenly jumped to talk about disk latency and
about sectors.  When data is defragmented it is done so by grouping the data,
but not into sectors (which btw currently might have no correlation to the
placement on disk).  Data in contiguous space (addresses) on the disk are
considered to be close to each other, which generally means close by wrt
tracks/cylinders.

> All this assumes that there's no scheduler optimizing access.  A smart I/O
> scheduler could handle access to a continuous placement across the platter
> much better than putting all important files in one area by sequencing
> the reads and writes for each application according to the current position
> on the disk.

Schedulers are a different beast, but they still benefit from files being
close by.

Nacho

-- 
"In Googlis non est, ergo non est." - Anonymous Coward
Homepage:       http://www.cse.ucsc.edu/~isolis/  |  EEE8 08C9 FBAE B471 9691
GPG Public Key: http://www.igso.net/isolis.gpg    |  CE7A 1CC8 D3DE B31E 10AB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://sluglug.ucsc.edu/pipermail/sluglug/attachments/20051003/323cc5d5/attachment-0002.pgp