[Sluglug] new to the list

[Ignacio Solis]

* cerise at armory.com (cerise at armory.com) said:
> In response to my suggestion that the filesystem spread files out around the
> disk, you responded:

Either we disagree what "spread ... around the disk" means or you're wrong.

> > That doesn't make sense. If you want fast access (seek time) you want all
> > the files close to you (the head), hence you move them close together.
> > You'll achieve nothing if you spread them out... other than increasing the
> > seek time from one file to another.
> 
> Fast access tends to imply minimal disk latency.  Minimal disk latency in
> this situation implies that you follow my recommendation in my last post.

First sentence true, the second doesn't explain itself.

> You are correct that it is defragmented by grouping the data and attempting
> to make the maximum use of clusters, however that only ensures fast access of
> the file if you're in the right place at the right time which happens very
> infrequently.  In fact, it happens even more infrequently (as I showed in my
> last post) if you group all frequently accessed files into one location on
> disk as you indicated to be a poor idea with the last sentence of that quote.

Do you know how addressing in a disk works? What the relation of address 1 is
to address 100? How cylinders and sectors are organized? what is considered to
be "close" to each other?

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

No.

> Schedulers attempt to optimize reads and writes based on the current
> position of the head over the disk.  If the frequently accessed files are
> close by (read: localized to one region of the disk), then it will have a lot
> of work for the disk when it happens to be in that region and almost no work
> for it the rest of the time.  

Hence it will spend more time in that region and waste no time on seeking to
the other side of the disk.

> It runs the rather believable risk that it will
> have too much work to do in that region and not complete all reads/ writes
> while the head is over that region.

What?  You mean that it will have less work if on top of that it has to seek to
another track?

> However, if frequently accessed files are continuous and spread throughout
> the surface of the disk, that work is spread over the course of the entire
> rotation of the platter and is much more likely to be a workload which the
> head can perform.

It seems clearer to me that we disagree on what "spread around the disk" means.
To me it means on a disk with addresses ranging from 1 to 100 it any one
address will have the same probablilty to have data, hence "spread around".  If
you mean to say that it is on a track/cylinder (hence from one point, you turn
the disk and cover some space), then that's not "spread around", that is
defragmented into contiguous space. Obviously you want to fill all the track,
and if you need more space go to the next track and so forth.
 
> One might note that if only one file is being accessed by one application,
> then this recommendation is no worse than yours.  In any situation where
> multiple applications are accessing any number of files, then it is trivially
> better than your recommendation as shown.

I've no idea what trivially means to you, but if what you want is proof that
putting everything together is the best thing, here is the proof done at IBM 
in 1973:

"Placement of Records on a Secondary Storage Device to Minimize Access Time"
Grossman D.D., Silverman H.F., Journal of the ACM July 1973.
http://portal.acm.org/citation.cfm?id=321775 

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/7b070eb6/attachment-0002.pgp