Filesystem API unusable (yet)

[noxer]

Todo on the file system API:

• Support file paths (we currently only support files in the current directory)
• Support for hooks (so we can implement "mount" and device files)
• Support for creating, moving and deleting files and directories
• Support for resizing files
• Support for defragmentation of the vfs

[rustyoz]

For the paths what if we treat slashes as a form of cd command. It might for the Shell atleast.
For example

cd /Programs/Shell/ would be broken into cd / cd Programs cd Shell.

Other than that once we have a disc spec we could set up a more expansive table to hold the file information.

instead of having files tied to a directory ID, they should tied to a directory located somewhere in the FAT table. For example if a file was in directory 24, the directory entry would start at word 20*24 = 480 beginning from the start of the disk.

One problem i foresee is that if you are reading sectors from the disk in chucks of 512 words, then it would make sense to have FAT entries some factor of 512 long. (ie 32) or else an the last entry of the in that sector is cut off. unless you get 5 sectors at a time (512_5= 128_20).

Chessmaster had a post discussing file systems on the forum. the 720 pages of 1024 words makes sense. Using the 16 pages for boot and FAT, that would leave 704 pages for files. but 15 pages for the fat also makes sense 15_1024 = 768_20.
With 768 entries in the fat table at 20 each, that leaves room for 64 folders that only exist in the FAT table.

[chessmaster42]

1. I think that just splitting it out into multiple commands will work just fine. If it ever gets too slow we can revisit it.
2. Directories are in fact in the FAT table now. They have the same 20-word entries as files. Do you think this needs to change? And if so why?
3. Yes, we can bump up file entries to 32 words so everything is aligned. I think that more meta data like timestamps, symlink data, and permissions would be appropriate to fill in the next 12 words that we're adding. Give 2 words for modified, 2 for created, 1 for symlink, which leaves 7 extra. Permissions can just be added to the flags. Thoughts?
4. Pages on the FS are 512 words not 1024 like in RAM. Makes it easier since the sector size on-disk is 512. This means that the first page is the boot sector then 159 for the FAT. That leaves 1280 sectors for files and gives room for 1280 files and 1264 directories in the FAT. The numbers are still kinda screwy so please help me get this optimized.

[rustyoz]

->2. i don't think they should be removed from the FAT. for optimisation though if you reference (where you know what file you are using, as opposed to searching for it) a directory or file it is done by the directory id or file name. for example you might load a program and it find a file in the FAT, but to find its owning directory you would do a linear search for the directory ID, but if the index of the FAT for the directory entry was stored as well you could jump straight to it.

for the small number of files currently linear searches are no problem. and if they are stored to begin with at the start of the FAT it makes it less of a problem, but if we get to the stage of creating, deleting file and folders. entries would start to get placed all over the FAT table. Also when doing linear searches of the floppy disk, it is quiet possible that every page from the fdd FAT would need to be read to jump back to a directory.

->3 It would reduce the capacity of the disk in the long run but dealing with file entries stretching over the page length would be annoying. For 20 word entries all we would need to do it page 5 sectors to ram to give us a block of words with a factor of 20. The extra meta data would be useful too. Thinking along these lines if we had 24 word entries, three pages would give as 1536 words, or 64 entries.

I'm thinking that we should allow to much head room for extra folder. How many folders will one need on a floppy disk?

I think i good size would be 94 sectors for boot sector and FAT, leaving 1346 for files and 638 spare entries for directories.

[noxer]

We should keep the VFS and the Floppy Disk's FS apart. IMO the VFS should be used like "/" in *nix OS's. We keep it as a part of the kernel's data and mount other disks to "/mnt/diskX/". With the hooks mentioned in the first post we can link files and dirs with the necessary functions in the drivers so they can map their data into it. So we can allow applications to access different filesystems without having to deal with drivers. We can also map the processes to "/proc/".

[chessmaster42]

I like it. Sounds like a good idea to me. We'll have to keep the contents of the VFS as tiny as possible though

[chessmaster42]

I think this is the format we should use for the file entries on the floppy disk itself: http://en.wikipedia.org/wiki/8.3_filename

It's 32 bytes but since we're using words I think we can modify it slightly to give us 16.3_filename as our format:

0x00 - 0x0F: Filename
0x10 - 0x12: Extension
0x13: Flags
0x14: Reserved
0x15: Create time fine resolution
0x16: Create time
0x17: Create date
0x18: Last access date
0x19: Reserved
0x1A: Modifed time
0x1B: Modifed date
0x1C - 0x1D: File start
0x1E - 0x1F: File size

[chessmaster42]

And I think for the floppy filesystem we should build a driver to support the standards committee format here: https://github.com/0x10cStandardsCommittee/0x10c-Standards/blob/master/FS/Draft_Harrys_Allocation_Table.txt

[rustyoz]

has there been any decision on the file system we are going to support or are we waiting until the we get a disk spec?