hamilton@uiucuxc.CSO.UIUC.EDU (10/15/86)
> -I think it would be a good idea NOT to put the first data block on the same > cylinder as the file entry. You would then have double then number of > sectors on that cylinder to put file headers. i think this was supposed to be a feature, so those small icon files would cluster close to the directory and file headers. hence the notable speedup in icon plotting when Workbench drawers are opened. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/17/86)
>> -I think it would be a good idea NOT to put the first data block on the same >> cylinder as the file entry. You would then have double then number of >> sectors on that cylinder to put file headers. >wayne hamilton: > i think this was supposed to be a feature, so those small icon files >would cluster close to the directory and file headers. hence the notable >speedup in icon plotting when Workbench drawers are opened. You're correct. However, you took my words out of context. The idea is that if you have multiple track buffering, you still want to group the first data blocks together, just not put them on the same cylinder as the directory. C-A's idea of putting the first data block on the directory track is a feature only if you do not have multiple track buffering, which we currently don't. If you think about it, *everything* will go much faster with multiple track buffering and read-ahead. -Matt
hamilton@uiucuxc.CSO.UIUC.EDU (10/20/86)
>>> -I think it would be a good idea NOT to put the first data block on the same >>> cylinder as the file entry. You would then have double then number of >>> sectors on that cylinder to put file headers. >>wayne hamilton: >> i think this was supposed to be a feature, so those small icon files >>would cluster close to the directory and file headers. hence the notable >>speedup in icon plotting when Workbench drawers are opened. > > You're correct. However, you took my words out of context. The idea >is that if you have multiple track buffering, you still want to group the >first data blocks together, just not put them on the same cylinder as the >directory. C-A's idea of putting the first data block on the directory >track is a feature only if you do not have multiple track buffering, which >we currently don't. > > If you think about it, *everything* will go much faster with multiple >track buffering and read-ahead. if you have multi-track buffering, _and_ your buffers are full of useful data, you don't care if the file headers are segregated on cylinder A and first blocks on cylinder B, or if they're mixed together across both A and B. but if you _don't_ have multi-track buffering, perhaps because you're a consumer with a 256K machine, maybe you _will_ care. and what about when the intuition user inserts and opens a new disk? the track buffers are empty, but you want to get those icons on-screen as fast as possible. the file system _does_ need some tinkering. but rather than trying to devise some one-size-fits-all "ideal", i'd rather see something more adaptive. there's still room for performance gains from minor changes, like following those next-block pointers instead of reaching for the file header/list blocks. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton