john13@garfield.UUCP (John Russell) (10/24/87)
-- While the discussion about the faster hard disk filesystem is still on the go, and with Leo's filesystem ideas not too far in the past, can someone tell me why it's terrible, heretical and wrong to even think about doing the following? - An optional command line interface, maybe called "altcli". This would test to see if an executable existed in the alternate sub-filesystem before calling the regular AmigaDOS loader if unsuccessful. - A file in a disk's main directory called, let's be original, "alt-dir". This would be a file with blocks stored contiguously, and contain the special directory info for the alternate files; all the things people have been complaining are in inefficient places, in files instead of the directory or scattered randomly around the disk. - A library of I/O routines to supplement all the fopen(), etc calls, and so that any programmer could make use of alternate fs-files and create his own. - Executable, data and other files, maybe with a special format for each (ie open MODE_DATAFILE or MODE_EXECUTABLE to read or write). These would be stored again contiguously on disk to minimize seeking, by direct manipulation of the diskblock bitmap. A partially full disk would be considered to have XXX blocks free for the alternate files, even if this was a fair bit less than the total number of free blocks. There would also be a "largest allocatable chunk" which would limit the size of a single file you could create. However empty space would still be available to the regular filesystem. * This "mix and match" method of storing files is used by an Epyx product on the C64, called "Vorpal", and gives a 25X speed increase in load time. They don't use subdirectories, instead the filetype is set to a normally illegal value something like the way C-64 Geos uses modified sequential files (type USR) for executables. - I guess if you are going to assume some control over the disk's bitmap you would need an alternate disk-validator that would handle disks both with and without any alternate files on them. Like I say, this has already been done on the C64, and this yields a about a 5X increase in speed over all the hardware and software hacks that have been done to speed up normal disk access (eg Fastload, Turboload, Flash). Sure, it's mostly of benefit to programmers who like to configure their disks for their own convenience... but then that's my intended audience with this posting. It doesn't require a hard disk for almost instantaneous retrieval, and allows for both old and new types of files on the same disk without conflict. (This is one of those "if I knew BPTRs and Ex_Nexts and SendPacket()s I'd do-it-myself type of projects. Since I don't, someone else please do it! :-) John -- To preserve deniability, I have not informed the University of this posting. But if I had, they would have been 100% behind it, yessirree bob. This posting has statements that are evasive, misleading, and just plain wrong. But that is only because I love the UseNet with urfch ice
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/25/87)
:- A library of I/O routines to supplement all the fopen(), etc calls, and : so that any programmer could make use of alternate fs-files and create his : own. You can actually write your own filesystem if you want, and install it into the system without having to touch any high level library routines. You simply tell DOS not to use, say, DF1:, then run your own custom filesystem on that drive as a DOS device. Poof. The reason it hasn't been done yet is simple. Yes DOS is slow... but it isn't *so* slow that people get totally fed up with it; writing your own filesystem is a pretty good sized project... -Matt