dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/05/86)
I don't much like the workbench's ICON scheme either. It doesn't work well with the Amiga's directory structure. I don't think it would be a major hack for C-A to simply put it all in a single file with a known name. That would get rid of all the $#% directory traversals and make the workbench windows and icons come up almost instantaniously. If this file didn't exist (say, the file is called .icons instead of .icon), the WB would default to the old method (if you really want to keep compatibility). Using such a scheme, you could impliment addition/deletion much like a UNIX directory entry.... you don't actually delete the space when you delete an icon, just free it up for other entries. For something like this, there would be no need to actually 'insert' icons when you add them, just append them to the file or find a hold to put them in. There is another advantage to using this new system: The disk doesn't get as cluttered. I really hate seeing all those .icon files strewn around my disks in the middle of the *real* stuff. -Matt
hadeishi@husc4.harvard.edu (mitsuharu hadeishi) (10/05/86)
In article <8610050713.AA13268@cory.Berkeley.EDU> Matt writes: > I don't much like the workbench's ICON scheme either. It doesn't >work well with the Amiga's directory structure. We were discussing this issue at length on the Well (a topic started by Jim Goodnow of Manx C fame and contributed to by many Bay Area hackers including a few of the Amiga OS designers now and then) about the speed of directories in particular. It was pointed out (by me) that an important issue to consider was the appropriateness of a filesystem/OS design to the performance of an icon based/graphic oriented user interface. I mean we just couldn't design in a vacuum; some considerations should be made as to how this OS is going to be used. The C-A hackers were all in favor of dumping the filesystem for a whole new filesystem while there was still time, but Commodore- Amiga was totally against anything that would be incompatible with 1.1. So despite a lot of intelligent and less intelligent argumentation, the issue finally died. However, some of out comments were taken back to C-A by the C-A hackers who had contributed to the discussion, and apparently the disk sector allocation scheme was changed in 1.2 to reflect the design of Workbench icons. Apparently if you have a very small file the 1.2 allocator attempts to allocate it as close to the home directory track as possible. Space is "reserved" for these small files near the home track, or something of this nature. In any case the upshot is because of this icons are displayed MUCH faster under 1.2. The Workbench icons seem to come up at least 2 to 3 times faster, and if you use AddBuffers they typically come up even more rapidly. This new system is totally compatible with 1.1 (since it is just a change in the allocator) and yet gives a MUCH more professional appearance to icon display for disks written under 1.2. -Mitsu
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/13/86)
In article <331@husc6.HARVARD.EDU> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: > However, some of out comments were taken back to C-A by the >C-A hackers who had contributed to the discussion, and apparently the >disk sector allocation scheme was changed in 1.2 to reflect the >design of Workbench icons. Apparently if you have a very small file >the 1.2 allocator attempts to allocate it as close to the home >directory track as possible. Space is "reserved" for these small files >near the home track, or something of this nature. In any case the >upshot is because of this icons are displayed MUCH faster under 1.2. >The Workbench icons seem to come up at least 2 to 3 times faster, >and if you use AddBuffers they typically come up even more rapidly. >This new system is totally compatible with 1.1 (since it is just a >change in the allocator) and yet gives a MUCH more professional >appearance to icon display for disks written under 1.2. > > -Mitsu I wrote a hack some time back called "fm" that gave you a visual picture of sector allocation of files on the disk (yes, I did throw it at the net). Here are some of the observations I've made. Under 1.1, data blocks grow downward toward track 0, file info blocks grow upward. Data blocks for a given file are kept as close to each other as practical; file info blocks for a given file are arranged similarly. File info and data blocks are rarely near each other. Under 1.2, the very first data block is *always* right next to the file header block. This is what makes icons come up so fast under 1.2. Data blocks subsequent to the first one are allocated as per the 1.1 scheme. However, this is true for all files, no matter what their size. So if you have a lot of 2-block files running around under 1.2, your sector allocation will look very strange indeed. Under both OS's, data blocks grow toward track 0. Upon getting there, the allocation algorithm wraps to *TRACK 79!* So if you've got a file that spans this boundary, you'll hear, "tic tic tic tic tic BRRRRAAAAPPP!! tic tic tic..." This is one of the bigger misfeatures in the DOS allocation scheme as far as I'm concerned. It would be "trivial" to allocate from the center out growing upward once you'd filled the lower half (wouldn't it?). It's also somewhat amusing to observe the effects of fragmentation after a disk has been used a while, especially for big files. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab ihnp4!ptsfa!well!ewhac The Guy in The Cape ..or.. well ---\ "Work FOR? I don't work FOR dual ----> !unicom!ewhac anybody. I'm just having fun." hplabs -/ ("AE-wack")