about file systems,..and asm coding///

one sector is 512 bytes.
one file that is less than 512 bytes use One secotr or cluster.

this kind of stuff is:
easier to manage than secotrs.
wastefull because of minimal cluster size beeing enormous..


a hobby machine contains a lot of little files (less than one sector)


then, i think i will make a simple implementation of fool in a linear format.

a file will be in a linear address space on th edisk.
one sector can then contain more than one file.

this implementation will be fool (of course) and a file service will read the drive in a buffer, and move it to the work space of the application.

the application will have a node to contain files.
files will be pointed in ram dirrectlly on the return of file read service.

the file organisation will be fool oriented (of course)and the folder willl tell you what sort of file it is.
the file service will use a set of pointers specific to the file type and load it in the right address (if needed).

what do you think of this idea?

I agree here, and I disagree here, we do not NEED 512 bytes for a boot sector
but, I like making 512 OSes, so ya know.


most of my programs are about 30-197 bytes.



I like it ^_^

This is very similar idea for the filesystem to the one I once implemented in my Titan OS for the RAM drive. You can find it in the remaining Titan sources - at least this part was not lost.

How do you handle extending/shrinking a file? How do you reclaim space from deleted files?

If you're askng about my implementation, then: there files still could be fragmented, only they were not fragmented into clusters, but into "bubbles" of any length. When file was deleted, the these "bubbles" were marked as free, and if two free "bubbles" were adjacent to each other, they were merged into one larger bubble. The file system started as just one big bubble itself - creating the new files would cut out new small bubbles from it. When the existing file needed to grow up and its bubble had no free bubble after it to steal the space from, the new additional bubble was created and linked to the first one - this way file would get fragmented (just a kind of linked list, with blocks of variable length). When you truncated a file, the last bubble would shrink in size, so a new free bubble would be created after it (or perhaps merged into the following free bubble, if such existed).

When looking at my explanation, I now think I should call it "bubble file system". The implementation in Titan was complete, though I recall there were some bugs that I fixed later (so the fixes were lost with all the later sources), so I must warn this one may still be buggy on file deletion (if I recall correctly).

I imagine multitasking with a bubble FS would be quite awkward.

imagine multitasking as an abstration.
then, in reality, it is a single task, with many context switches.

then, bubble fs would be a little good.

but...one thing is always required.
the marquing of sectors in a drive map (for security reason). one byte=1sector 0=free, 1=occupied or dead.
this layer should be transparent.
the user don't have to manage it, but he can.

the sector map should be organised as a single bitmap or a tree.
a tree is a little slow but organised and clean.
a bitmap file is not diffucult to manage, linear access to drive, but cannot really contain a complex structure. and it will be complicated to access the meta datas.

a tree will be organised in 3 levels or more.
first level will be the complete drive (or any unit), the drive map will show the usage of each cilinders, and then, each cylinder item will dive into the cylinder, and show the cylinder map.
the cylinder map will do as above with heads.
and dive into head map.
head map will be different because it will use the strict minimum.
1bit per sector.
to seek free space, first, give the space needed in bytes, and ask for space in drive you want when you use f.disk function.
it will be transparent and will return an error if not possible to do what is asked.