flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Linear file system then, LFS64.

Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4333
Location: Now
edfed 20 Apr 2009, 18:08
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?


Last edited by edfed on 05 Dec 2020, 12:15; edited 1 time in total
Post 20 Apr 2009, 18:08
View user's profile Send private message Visit poster's website Reply with quote
Coddy41



Joined: 18 Jan 2009
Posts: 384
Location: Ohio, USA
Coddy41 20 Apr 2009, 18:46
edfed wrote:
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..

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.

Quote:

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

most of my programs are about 30-197 bytes.


Quote:

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 like it ^_^

_________________
Want hosting for free for your asm project? You can PM me. (*.fasm4u.net)
Post 20 Apr 2009, 18:46
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland
Tomasz Grysztar 20 Apr 2009, 20:46
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.
Post 20 Apr 2009, 20:46
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system
revolution 21 Apr 2009, 01:23
How do you handle extending/shrinking a file? How do you reclaim space from deleted files?
Post 21 Apr 2009, 01:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland
Tomasz Grysztar 21 Apr 2009, 05:48
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". Very Happy 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).


Last edited by Tomasz Grysztar on 21 Apr 2009, 11:55; edited 1 time in total
Post 21 Apr 2009, 05:48
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system
revolution 21 Apr 2009, 07:33
I imagine multitasking with a bubble FS would be quite awkward.
Post 21 Apr 2009, 07:33
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4333
Location: Now
edfed 23 Apr 2009, 18:14
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.
Post 23 Apr 2009, 18:14
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.