ajk@goanna.oz (Alan Kent) (02/18/88)
> AmigaDos should sort disk requests by track. ... ... > This would eliminate thrashing, and would speed up disk accesses to boot! ... > How major a change in AmigaDog is this? The simplest way to stop AmigaDos thrashing would be to make the trackdisk.device cache more than one track. This should not be very difficult and would not involve touching AmigaDos. It would however require consume more memory. What happens now when accessing two files is that the trackdisk reads one track to get a single sector, but then has to go off somewhere else to get another single sector for the other file. This causes the first track to be lost forcing it to be reloaded to get the next sector for the first file. AmigaDos does seem to allocate contiguous sectors most of the time. Buffering say two tracks would cause thrashing at a track level rather than a sector level, but at least this is an order of magnitude better and still keeps good concurrency. Buffering multiple tracks also helps with directory listings. I wrote a harddisk driver which buffered 5 tracks with a bit of intelligence about which buffers to discard and it made a huge improvement. I dont think sorting disk seeks would help that much. Programs which cause a file to be read sector by sector (rather than doing read/writes which are multiple sectors long) would still thrash if you sorted the seeks due to the synchronous nature of the Read() and Write() calls. At any one time there would only be two read requests in the queue (if two separate processes are reading files). Due to the delay between requests for reads by the program to the same file, Dos would have already said "well, I've only got one thing left in the queue so I will go get that now". You would have to delay the actual disk access until you were sure that another request for the same file was not going to arrive. Tricky! So, anyone want to rewrite "trackdisk.device" and have a new command "settrack <trackcachesize>"? You could get rid of addbuffers if you wanted to. Perhaps it could be put in 1.3. Alan Kent (RMIT, Melbourne, AUSTRALIA) UUCP: {uunet,hplabs,mcvax,ukc,nttlab}!munnari!goanna.oz!ajk ARPA: munnari!goanna.oz!ajk@SEISMO.ARPA ACSnet: ajk@goanna.oz (is there a standard international way of doing addresses yet?)
dale@boing.UUCP (Dale Luck) (02/22/88)
In article <1177@goanna.oz> ajk@goanna.oz (Alan Kent) writes: >The simplest way to stop AmigaDos thrashing would be to make the >trackdisk.device cache more than one track. >So, anyone want to rewrite "trackdisk.device" and have a new command >"settrack <trackcachesize>"? You could get rid of addbuffers if you >wanted to. Perhaps it could be put in 1.3. >Alan Kent (RMIT, Melbourne, AUSTRALIA) The trackdisk driver as originally written did have more than 1 track buffer. We had to limit it to 1 though to keep all those 265k systems working. Maybe it is time to rethink this strategy and let it loose again. It should probably check the available memory at power on and automatically grow it trackdisk cache. Adding a new command like addbuffers for us programmers would be good as well. Dale Luck
john13@garfield.UUCP (John Russell) (02/23/88)
In article <107@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >Adding a new command like >addbuffers for us programmers would be good as well. How about... FaccBuffers? If CBM was to make the effort (by endorsing, licensing, or whatever) to ensure that high-quality software, PD, commercial, shareware, etc was either included with a system or available easily to the firt-time user it would enhance the Amiga's reputation, especially amongst business users who very often don't read Usenet or belong to user's groups. Note that I DON'T include Textcraft et al in my definition. Too many times CBM has thrown support behind products that had obvious serious deficiencies. John -- "Fanaticism is all right... as long as you're ALONE! HAHAHAHA!" -- Pat Robertson shares a gem of wisdom told to him by Richard Nixon, and thus becomes the first politician to whom I can honestly apply the term "scares the willies out of me"
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (02/23/88)
In article <107@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >The trackdisk driver as originally written did have more than 1 track >buffer. We had to limit it to 1 though to keep all those 265k >systems working. Maybe it is time to rethink this strategy and let it >loose again. [ ... ] O most exhalted and omnipotent one, methinks thine performance- increasing strategies are misplaced. Personally, I'm a believer in functional seperation. IMHO, the trackdisk.device should not be trying to second-guess the guy making requests of it. Its sole responsibility should be to get them bits off the media and into memory. It should also know how to move the head around so it can find them bits. If anyone should be responsible for caching disk data, it is the client to the trackdisk.device (in this case, the filesystem). Only the client program "knows" what its behavior is going to be like, and only it can make intelligent decisions regarding caching. The client can also copy its caches out to FAST RAM if it exists. The blame for poor filesystem performance rests squarely on the filesystem. The trackdisk.device shouldn't be mucked around with simply because Tim King was a <insert your favorite insult here>. Besides, you may be shooting yourself in the foot if and when a new filesystem comes along. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
dale@boing.UUCP (Dale Luck) (02/24/88)
In article <5282@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <107@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>The trackdisk driver as originally written did have more than 1 track >>buffer. We had to limit it to 1 though to keep all those 265k >>systems working. Maybe it is time to rethink this strategy and let it >>loose again. [ ... ] > Personally, I'm a believer in functional seperation. IMHO, the >trackdisk.device should not be trying to second-guess the guy making >requests of it. Its sole responsibility should be to get them bits off the >media and into memory. It should also know how to move the head around so >it can find them bits. However it is the trackdisk device that decided to treat the floppy disk as something you can only read and write a track at a time instead of a sector at a time like most other mass storage devices. So forcing the file system to know about the peculiarities of the device is forcing the file system to be more intelligent then maybe we should make it. The same kind of problem occurs with scsi devices. Scsi was invented so that a filesystem of some nature could deal with logical sectors, a whole bunch of them. However the to get the max performance from a complete system it helps to inform the file system that your hard disk is split up into 4 heads 900 cylinders and 17 sectors per track. Instead of some other configuration. If we can speed up this mess by appropriate buffering in the trackdisk device then other file layout strategies may be able to take advantage of this level of buffering as well. Kind of like magic. Dale Luck Boing
morgan@brambo.UUCP (Morgan W. Jones) (02/29/88)
In article <5282@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > If anyone should be responsible for caching disk data, it is the >client to the trackdisk.device (in this case, the filesystem). Only the >client program "knows" what its behavior is going to be like, and only it >can make intelligent decisions regarding caching. The client can also copy >its caches out to FAST RAM if it exists. To an extent, you are right. If anything is going to cache sectors from the disk, it should be something at a higher level than the trackdisk.device. However, the trackdisk device should cache tracks, at least until the simulataneous access problem is solved. This is because the trackdisk.device accesses by tracks but only returns sectors; thus two processes accessing files at the same time will cause the same tracks to be re-read several times. The filesystem could cache sectors 'till it was blue in the face and it still wouldn't solve this problem. >Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."
karl@sugar.UUCP (Karl Lehenbauer) (03/02/88)
In article <5282@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > In article <107@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > >The trackdisk driver as originally written did have more than 1 track > >buffer. We had to limit it to 1 though to keep all those 265k > >systems working. Maybe it is time to rethink this strategy and let it > >loose again. [ ... ] Perhaps number of trackdisk buffers could be settable. Two drive systems would be incredibly faster if the number could be set to, say, 320. (no smiley - it's only 1760k bytes after all, not outrageous in the modern era) > Personally, I'm a believer in functional seperation. IMHO, the > trackdisk.device should not be trying to second-guess the guy making > requests of it. Its sole responsibility should be to get them bits off the > media and into memory. It should also know how to move the head around so > it can find them bits. I agree that trackdisk.device should not try to understand or interpret the contents of the data at a logical level higher than as a bunch of bytes. ...and if you're *not* saying that the filesystem shouldn't cache whole tracks, I take no issue. But I think that, if one has enough memory, caching at the track level is a major performance win, because it will always end up with more data in the cache, sooner, than any higher-level kind of caching that would not be putting everything it got from trackdisk.device into the cache. (...pity the filesystem wasn't designed to take advantage of the track-at-a-time characteristics of the drive hardware. On the other hand, tieing the OS too closely to the hardware causes problems later - like with hard disks.) -- "Lack of skill dictates economy of style." - Joey Ramone ..!uunet!nuchat!sugar!karl, Unix BBS (713) 438-5018