I have a question about the file system? Is it possible to create a file
system in which each block "knows" the location of the previous block? This
way the FAT can be slimmed down because only the location of the last block
of each file should be cataloged and the files can be read from the end to
the beginning, each block directing the hard drive where to look for the
next one.

So the recording is done from the beginning to the end of the file and the
reading is done in opposite direction.

There are many, many ways to handle file systems. I use a simple block-based file system (1k blocks), where a file gets an entry like:



It's very simple, and quite effective for a small OS.

Your idea would works just as easily the other way: have each block know the location of the next block. You'd have a chain of blocks, with some metadata in each block, and terminate the chain with "0" or something like that. Then you could read the file in the correct order and still only have the name & initial block number in the FAT

you can create every filesystem you want!!! i created my own, too, but the manual about it is in German... maybe i'll translate it.

Well, I don't know about your computer but mine is old and she can not predict the future. If I ask her to figure out where the blocks might fall she most likely will get beck to me with some sarcastic remark like "You want ME to guess?"

The problem with linking the blocks is slowness.
You read consecutive sectors off the disk straight into memory if the links aren't stored in the data, otherwise it is complicated or you have to do a lot of moves.

Are you sure that it is how it's being done, the consecutive sectors are read in the batch, or is it your guess?

No. They are.

Let's say you have a file on block 5.

How would you know where block 5 is? You follow the pointer in block 4.
But that assumes that you have block 4 in memory already. If not, you read block 4.

How would you know where block 4 is? You follow the pointer in block 3.
But that assumes that you have block 3 in memory already. If not, you read block 3.

How would you know where block 3 is? You follow the pointer in block 2.
But that assumes that you have block 2 in memory already. If not, you read block 2.

How would you know where block 2 is? You follow the pointer in block 1.
But that assumes that you have block 1 in memory already. If not, you read block 1.

Now that you have block 1, you can follow its pointer to block 2. You can then sequentially get blocks 3, 4, and 5. So you read _all_ of the blocks up to the desired block.

One way to reduce the amount of copying/moving is to use caching, in which you either store each block read somewhere in memory for future access or save only the pointer to each block. You still end up reading much of the disk.

well, I think the biggest problem is, that the writing of all the files is easy, but what, if you delete a file? then there are for example 5 blocks in the middle free... and then they are only useable, if you make a moving with all the following files 5 blocks forward or wait for a file, which is 5 blocks big! much free memory is unuseable without movings...

Not really.
This FS uses something like a linked list, which is really easy to manipulate (insert, delete, ...).

A file does not have to occupy sequential blocks. If each block has a link to the next block, then you can have a file A, for example that resides on blocks 1,5,2,3, and 9:

1->5->2->3->9

Removing a block is easy too, just set the pointer of the previous block to the next one. To insert involves a similar action.

Then, of course, you'd have to keep track of which blocks are free. Then you can have a block that holds a list of free blocks. If you need a block, just find a block here, link it in, and remove it from the list. If you delete a block, just return it to this list. Except, it's now getting closer to a FAT, except the table is for free blocks.

joachim_neu: I am thinking of this problem too. I'll have to figure that out, before i start implementing my own FS.
mastermind: I want all files to be in order, without fragmentation...

You should keep using FAT until you have your new filesystem ready. Then you could make a driver or something. That way, your OS supports multiple filesystems, which is good.

Oh yeah. Bubach, I'm using your bootloader+secondstage for my own OS. I was using bootf02 before, but it was so tightly packed that I couldn't remove the paging code without breaking something (I wanted to do that in the kernel). Then I switched to GRUB, which wasn't good either, because I cannot execute any realmode code without either switching back into realmode or using v86. Your's was the only loader that I could successfully adapt for my purposes. Thanks!

Thats what i am doing..

Hmm... Then perhaps once in a while, like in 10min intervals, you could run a diskgarbagecollect function or something. I cannot see any way right now to fix that problem.

Aiight. Gotta go to class now. bbl.

Yeah, i was thinking of doing some file-moving, when a specific size is needed. But i guess thats going to be slow. Installing software and get a 10min delay for file-moving..
Skip class? I (almost) only use school to get broadband access, as i live in the forrest..

Sorry for not getting back sooner.
With LBA you can directly specify which memory locations to load the blocks to.
If you use links within the blocks, you would have to load the block into memory and the transfer the non-link stuff into the destination memory.

The speed would especially noticied for consecutive sectors in a row.

..Gome73

Or you could do what toe programmers of MeOS did: read the whole disk into memory on bootup. It's faster to move stuff around in RAM. Then you could write everything to disk when the OS exits.

What do you mean, skip class? Today I had first period free, so I could hack around, among other things...

a clever idea, but if the OS breaks down? if there's a misstake or error, and the system reboots, all the work is away! and that's very bad! Or if you save when the misstake comes, you write the misstake on the floppy, too!

I don't think it's that clever.. only an attempt to get a slow asm os a bit faster..
ps: i don't mean to offend the menuet people, but menuet is slow for an asm os.

I agree with bubach, but i do not think its MenuetOS fault, you can not make a pmode, multitasking, OS using vesa, much faster.

PS: Is that slowwww pong games still in menuet ?.

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

I don't know if it's still being distributed, but I still have it on my MeOS disk .