ewhac@well.UUCP (09/23/87)
[ Forget the lawyers and guns; just send the money. ]
Some time back, I had delusions of writing a new dos.library. To
that end, I cooked up the beginnings of a filesystem specification. I've
since woken up from that dream, but I still have this slightly interesting
beginning for a filesystem base.
Having nothing better to do (actually, I have to start on the Killer
Demo entry), I thought I'd throw it you people and see what you thought of
it so far. There isn't much....
Incidentally, I was going to call this fictitious DOS "LEOS" (Leo's
Excuse for an Operating System).
--------
/* Block 0 of *ALL* mounted block devices. */
struct DevRootBlock {
ULONG ID = 'LEOS'; /* Not to be confused with 'DOS\0' */
UWORD NVolumes; /* # of volumes on this device */
ULONG VolumeKeys[NVolumes]; /* Block #'s where each volume root
block (start of volume) is
located. */
};
/* Root block for each volume */
struct VolRootBlock {
ULONG FADB; /* First Available Data Block
(absolute block number) */
ULONG VolSize; /* In blocks */
ULONG RootDir; /* Block # of root dir file */
ULONG BitMapSize; /* # of blocks in volume's block
availability map. Bit 31 ==
bitmap vaild flag */
char VolName[64]; /* Null terminated */
UWORD HashTabSize; /* # of ULONGS in a directory's
hash table. If NULL, directories
are searched linearly. */
UWORD HashCodeSize; /* # of bytes in hash code routine */
UBYTE HashCode[HashCodeSize]; /* Executable image of hashing
computation routine. Must fit in
what's left of block size; must
be position-independent. Passed
A0 pointing at null-terminated
string. Returns index into hash
table (0 ... HashTabSize-1) in
D0.w. Coded as subroutine. */
};
/*
* The above is the first "official" block in a given volume. The next
* BitMapSize blocks after that are (drum roll please) the bitmap blocks.
* FADB points to (ideally) the block just after all the bitmap blocks.
*
* The block availability bitmap is formatted as follows:
*
* Bitmap is stored as an array of bytes. Each bytes holds the status of
* four blocks, represented by two bits. The possible combinations are:
* 00: Free
* 01: Allocated
* 10: Bad block (format failed or something; avoid)
* 11: Invalid condition (used as consistency check)
*/
--------
I never got around to formally laying down a directory
specification, but basically it was going to be a magic header, followed by
HashTabSize ULONGS of hash table, followed by individual directory entries
(filename, file size, protection bits, etc.).
The way the directories would work is as follows: LEOS would pass a
filename to the hashing routine. It would return an index into the
directory's hash table. LEOS would go and fetch the value in the table at
that index. The value retrieved would be an absolute offset into the
directory file, which LEOS would then lseek() to get the file info.
Collisions would be handled much as they are now, except they'd be lseek()
pointers instead of block pointers.
Implications of the above
-------------------------
Floppies would be able to have multiple volumes per disk, which may
or may not appeal to people (sounds kinda neat to me, though I'd never use
it myself).
Directory listings would be perfectly quick, since directories are
now defined as files rather than gooey mish-mash. 'DIR'-type programs would
simply lseek() past the header and hash table, and start picking off
filenames.
We would still retain the advantages (if any) of hashing filenames
when opening files.
Hashing routines can be altered by the user or (more typically) by
the vendor on a per-volume basis. Thus, if some vendor has a strange
application that would benefit from a hashing algorithm different from the
default, they could install that on their distribution disk, and it would be
totally invisible to the user. The hashing function can be eliminated
altogether as well, saving space in the directory files.
Currently, there is no way for the AmigaDOS to robustly handle bad
blocks. This is especially bad with hard disks where the media can't be
swapped easily. The new block bitmap specification would help to alleviate
this problem. If LEOS detected a hard error, it could throw up a requestor
asking if the user wanted to mark the block as bad. LEOS could then try to
recover as much of the data as possible, then mark the bad block in the
bitmap, and the user would never be bothered by it again.
Problems I Thought Of
---------------------
Suppose we have a floppy that has multiple volumes on it. What,
then, does DF0: refer to? The raw block device? The first volume on the
media? This problem extends to hard drives as well (what does DH0: refer
to?)
One possible solution is not to have any hardwired device
references. This would quickly lead to people scratching their heads every
time they inserted a new disk ("What was this called again?"). Or they'd
name them all the same thing, which gets real interesting when they insert
two disks of the same name.
So there should be some form of hardwired device reference. But I
can't figure out a way to reconcile the multiple-volumes-per-device/what-
does-this-device-name-refer-to conflict off the top of my head. Anyone got
a neat solution for this?
------------
Oh well, there's my idea. Do with it what you will. Comments on it
are most welcome and encouraged. How many wheels did I re-invent? Will
this work nicely? Or should I stick to display hacks?
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac
O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorpeter@sugar.UUCP (Peter da Silva) (09/25/87)
Interesting idea. I like the multiple volumes. I don't like the hash tables. I like having directories as files (wonder why)? There's a good reason for storing the file name seperately from the file data: links. I'm sure you understand the advantages of these. How about storing the filename and file number in the directory, and then stick the rest of the data (maybe even with a filename, the way it is now) together at the beginning of the disk? Or stick it with the file and make the filenumber the first block number. After all... most of the time when you're looking at filenames that's all you want. As for the naming convention, how about taking a leaf from UNIX' book. df0a: first volume on the drive... df0b: second volume on the drive... The semantics of df0: wedge a little. diskcopy wants it to mean the whole drive. copy wants it to be the same as df0a:. For that matter what happens if you diskcopy df0a: df0b:? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
ewhac@well.UUCP (09/27/87)
In article <820@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Interesting idea. I like the multiple volumes. I don't like the hash tables. >I like having directories as files (wonder why)? > As I said in my original posting, I hadn't laid out a formal directory/file spec. However, directories under 'LEOS' are indeed files. The hashtable information is at the beginning of that file. >As for the naming convention, how about taking a leaf from UNIX' book. > >df0a: first volume on the drive... >df0b: second volume on the drive... > Hmm. Not bad. >The semantics of df0: wedge a little. diskcopy wants it to mean the whole >drive. copy wants it to be the same as df0a:. For that matter what happens >if you diskcopy df0a: df0b:? Grindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrind..... Actually, DiskCopy would suddenly have to become more intelligent. It would have to compare volume sizes (assuming we wanted it to operate on volumes, not just the raw block device). If the sizes were different, DiskCopy would abort. Interesting theories, no? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 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
hah@mipon3.intel.com (Hans Hansen) (09/28/87)
In article <4049@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>diskcopy df0a: df0b:? > > Grindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrind..... > > Actually, DiskCopy would suddenly have to become more intelligent. >It would have to compare volume sizes (assuming we wanted it to operate on >volumes, not just the raw block device). If the sizes were different, >DiskCopy would abort. > > Interesting theories, no? You should allow small file systems to copied into larger file systems as long as there is enough free space in the larger one. Hans
jdow@gryphon.CTS.COM (Joanne Dow) (09/28/87)
In article <4049@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <820@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>Interesting idea. I like the multiple volumes. I don't like the hash tables. >>I like having directories as files (wonder why)? > Actually, DiskCopy would suddenly have to become more intelligent. >It would have to compare volume sizes (assuming we wanted it to operate on >volumes, not just the raw block device). If the sizes were different, >DiskCopy would abort. Er, diskcopy is already that smart. That's why I had to create a special version of jd0: for Charlie Heath for his disk copying for program distribution. If enough interest is expressed I'll get Redmond to include that with jd0: on the Microbotics disk. -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.
andy@cbmvax.UUCP (09/29/87)
In article <1684@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >In article <4049@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>In article <820@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>>Interesting idea. I like the multiple volumes. I don't like the hash tables. >> Actually, DiskCopy would suddenly have to become more intelligent. >>It would have to compare volume sizes (assuming we wanted it to operate on >>volumes, not just the raw block device). If the sizes were different, >>DiskCopy would abort. > >Er, diskcopy is already that smart. That's why I had to create a special Correct. Diskcopy is, in this one instance, slightly more intelligent than Workbench. (ie, you have to run it from CLI rather than try to get it called automatically from Workbench by icon moving) -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
richard@gryphon.CTS.COM (Richard Sexton) (09/30/87)
In article <1085@omepd> hah@mipon3.UUCP (Hans Hansen) writes: >In article <4049@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>>diskcopy df0a: df0b:? >> >> Grindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrind..... >> >> Actually, DiskCopy would suddenly have to become more intelligent. >>It would have to compare volume sizes (assuming we wanted it to operate on >>volumes, not just the raw block device). If the sizes were different, >>DiskCopy would abort. >> >> Interesting theories, no? If this means: >You should allow small file systems to copied into larger file system(s) as ^^^^^ ^^^^^^ other THE >long as there is enough free space in the larger one. Then yes, this sounds like an interesting idea. >Hans -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."
peter@sugar.UUCP (Peter da Silva) (10/01/87)
> > It would have to compare volume sizes (assuming we wanted it to operate on > > volumes, not just the raw block device). If the sizes were different, > > DiskCopy would abort. > You should allow small file systems to copied into larger file systems as > long as there is enough free space in the larger one. You don't use diskcopy for that. You use "copy df0a: df0b: all". grindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrindgrind -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *valRESRES
manes@xanth.UUCP (10/02/87)
Question: Is it possible (feasable) to alter the Amiga drivers, or write a new driver that would support the new 1.44 MB floppy disks? It would be ever so handy if this could be done! I really think that it would be nice! -mark= ST Amiga]
grr@cbmvax.UUCP (George Robbins) (10/14/87)
In article <2630@xanth.UUCP> manes@xanth.UUCP (Mark Manes) writes: > > > Question: Is it possible (feasable) to alter the Amiga drivers, or write a > new driver that would support the new 1.44 MB floppy disks? It would be ever > so handy if this could be done! > > I really think that it would be nice! Me too, however it's not a software issue as the Amiga custom chips don't support 500 KB/S drives like on the AT or PS/2 machines. -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by mnoject:be