James Knott said the following on 02/16/2010 10:01 AM:
Anton Aylward wrote:
Lubos Lunak said the following on 02/15/2010 12:02 PM:
Well that isn't a explanation. In fact the guy admits he's a KDE developer and not a kernel hacker. I was, though not any more. kernel hacker that is. Disk drivers and file systems were my focus back then. Different technology, UNIX, not Linux, but some principles still hold.
The impression I got after reading his link is he was talking about grouping related files to minimize head movement, which is not the same as defragmentation. I have to wonder how he could be a developer and not know the difference. As for interleaving, I recall when that was necessary, because the computer couldn't keep up with disk data.
While disk driver software may issue a 'seek' to a particular track, that doesn't mean the head moves, even if it had just done a seek and transfer from another track. Reality is heads are "wide" enough to "cover" a few adjacent tracks - or cylinders. Back at the beginning of the 1980s, Berkeley came out with the "Fast File System" as an alternative to the old V7 file system. It used this idea to put files in groups - "cylinder groups" - so as to, as you say, minimise head movement when accessing related files. However we are now running mapped Virtual Memory systems. Files, for the most part, are not 'read in', they are paged in. In parts. As page faults demand. The idea of "extents" and - as you said, interleaving for slower machines - made sense when we were running the "roll-in/roll-out" model of V7 UNIX. You had to "roll-in" ALL of the executable before you could begin executing it and had to "roll-out" ALL of it to swap. In that case putting the file in a contiguous extent made sense. We don't do that now. We "map the file". And the libraries. So a program is 'loaded'. Well, no, its mapped in. Switch to suer space and go to "__start()". Oops! Page fault - bring in that page. There was a time the smarts said bring in the next few as well, but lets face it, the first thing the program does is call its initialization code, which is way over there ... more page faults ... then the command line scanner ... over there. Contiguous files don't make as much sense as they once did. And while the program is suspended waiting for the faulted pages to come in some other code is running and generating its own disk IO requests. And LO! There aren't the free pages available for all this IO, so some have to be paged out ... and that depends on the queueing mechanisms, which have a BIG impact on performance and disk activity. And don't forget, the swap partition is way, way over there, lots of disk head movement. Hmm. Why not put it on a separate spindle. Or flash memory? Ridiculously, if a code page has just been used its less likely to be freed, but that page with the initialization code isn't going to be wanted again ... So a lot of the algorithms are ... well, sub optimal. Its a hard life! -- Most people are not really free. They are confined by the niche in the world that they carve out for themselves. They limit themselves to fewer possibilities by the narrowness of their vision. --V. S. Naipaul -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org