HAT Standardisation Discussion

[eXeC64]

Any feedback, questions or suggestions pertaining to FS/Draft_HAT.txt should go here.

[hashmal]

Is the name chosen on purpose? It may lead to some confusion.

[eXeC64]

Just had a chat with people on IRC for new naming schemes and the general consensus was to change name to HAT, Harry's Allocation Table, like FAT. It's also a reference to notch's hat.

Also, masterm promised he'd write mkfs.hat if I called it hat.

[ghost]

Why are block_start, inode_start and content_size 2 words each? They can't be larger than 0xFFFF because RAM has only 0x10000 words.

[eXeC64]

Floppies are 1.4mb, so it all needs to be addressable. The data structure is on disk, not in memory.

[ghost]

2.2.1.4. is_writable
If this flag is set then it must not be possible to write to or
modify the file in any way other than changing this flag.

Shouldn't it be reversed? "If this flag is not set, it must not be possible to..."

[eXeC64]

You are correct, I'll correct that immediately.

[mxrth]

Another question about the is_writeable flag:
What are the advantages of this flag? I mean there is no real multiuser environment and if you want to write the file you just set this flag and write. It seems to be unnecessary overhead, which should imho be avoided when targeting the dcpu16.
(Same goes for the is_executable flag, whereby i understand that it could be handy to have this as a marker flag, dunno)

[chessmaster42]

Something to consider:

Our physical storage medium will be 1.44MB floppy disks. This will equate 720*1024 words of space. If we allocate pages at 1024 words then that gives us 720 pages to work with. Say the file table is a flat, sequential table where each file entry is 20 words long (1 for parent directory, 1 for flags, 16 for name, 1 for file start, 1 for file end). This means we can have up to 704 files (giving the first 16 pages to the boot page and file table). Now let say we want to find the 704th file in the system in the table. Lets also say that skipping over the wrong file (the first 703) takes 15 instruction cycles each time. That comes to approx 100ms to retrieve the file data.

Now that seems to be a perfectly reasonable speed to find the file given that file I/O on the floppy isn't a continuous process unless you're doing page swapping to swap RAM pages to floppy pages. And even in that case we could reserve the first 16 as above and the next 64 for RAM page swapping and the time to retrieve the page data for the last of those 64 would be around 10ms. And that would be if we're swapping ALOT of RAM at one time. Typically you'll probably be page swapping between 1 and 4 pages which brings that time down to approx 0.5ms. Now given that it will take about 100ms just to copy the page data (for a 1024 word page) that is a minimal overhead even at the end of the page swap space.

All of that to say this, why implement a modern filesystem? The number of files and space and speed potentials are lost on a system like the DCPU. We are working with a 100kHz CPU with 64K words of RAM and a 1.44MB floppy. We don't need anything fancier than a flat file table system with page swapping.

If someone can prove to me why HAT or any other variant of FAT12 or FAT16 is necessary I'll recant my evil ways :P