On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said:
> I've mentioned this elsewhere before... a small unix style pd filesystem is 
> available in C source form inside the UZI package on oak.oakland.edu It 
> doesn't use 32bit values just 16bit for speed and ease of z80 implementation 
> so each mounted logical drive is restricted to 32Meg in size.

That is way too small.  For a start, a lot of filing systems allocate disk
space in blocks (usually of 1K, i.e. two sectors) which would raise the
maximum size to 64M.  For a second, some filing systems further combine
several blocks into a zone.  With 4K zones, the disk can be 256M in size.
Using zones has the advantage that (a) larger disks can be addressed in 16
bits, and (b) files are recorded on the disk with more blocks close to each
other for faster access.  Of course it has a disadvantage too - the amount
of space reserved for each file is a multiple of the zone size so that a
few K can be wasted for each file (on the other hand, if the disk has size
256M, do we care about an average 2K per file waste?).

> As we're dealing with a fixed drive we can theoretically do what ever we like 
> as it doesn't need to be compatable with ANY other platforms physical format..

It is easier, however, if you can re-use someone else's code...

>                                                  partition large HD's it
> smaller logical units, after all who needs to process more than 32Meg items 
> on 
> a z80?

It's not the size of one file that counts - it's the extra trouble of
having to mess around with partitions.  Not having to remember the drive
letter for each file is a big plus for Unix IMHO.  Also it would be silly
to run out of space on one partition and have to start moving files here
there and everywhere even though the disk is only 1/3 full.

>  Si> I'm currently thinking of 64 chars per
>  Si> directory entry, allowing 20
>  Si> character (or so) filenames, with
>  Si> possibly a quick-to-access file system
>  Si> (ie one that is a combination of FAT and
>  Si> sector/head/track at the end of each
>  Si> logical sector (ala SAM)).

Why have a limit on the length of a directory entry anyway?

> 510byte sectors again Si!?! Makes for crappy random-access file performance!

I agree with that. :-)

imc

Reply via email to