> 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?).
Better not tell Bob then -- he wants drives less than 40Mb, or so it appears :) > > 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... Nope - not really. DOS evolved and evolved and it's so clunky it's unbelievable. And have *you* tried to get the Docs on the low level side of the HPFS used in OS/2? It's unbloodybelievably hard. I spent a good few months tracking down the ATA standard actually (IDE design specifications). For those who want it, btw, it's in ftp.dec.com, pub/standards/ata :) They've also got ata2, scsi1,2 and3 and a few more... > > 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. I'm considering allowing a linked-partition system, but not sure about how it'd perform speed-wise. Basically you can define two E-DOS partitions and link the data space together to form one big partition. It *may* work -- gotta look into it more. > > 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? Because it makes for easy and quick directory access without having to resort to a round-robin linked node structure, which I hate because it fragments the data area something rotten. > > 510byte sectors again Si!?! Makes for crappy random-access file performance! > > I agree with that. :-) Okay, that idea is now ditched. I'm considering using the logical-sector access mode of the IDE drive to store all stuff -- other people for other partitions can use the sector/cylinder/head method if they want :) This should speed up access -- you just take the sector number in the partition, add it to the logical start of the partition and read / write... quick 'n' easy :) Si
