design and implementation filesystem
Moderator:Moderators
sir, where can i start writing my own filesystem from scratch and implement it with c/c++?
Anywhere you want but I suggest it is in front of a computer else you will find using C/C++ rather hard - also I would suggest the presence of a pad of paper, a pencil and an eraser 
On the note of designing your own file system, mu advice would be DONT.
Many people who try to write their own file systems end up with one that is like FAT but not as good. The advantage of using already existing file systems is that there are no compatibility issues when trying to copy files across.
Sorry for the discouragement but its in your best interests (honestly)
~Andrew
On the note of designing your own file system, mu advice would be DONT.
Many people who try to write their own file systems end up with one that is like FAT but not as good. The advantage of using already existing file systems is that there are no compatibility issues when trying to copy files across.
Sorry for the discouragement but its in your best interests (honestly)
~Andrew
Okay, I sort of agree with Andrew, I do think that the chances of you being able to come up with a more efficent file system than the currently available ones is slim. I also see the want or even need to create one. I myself plan on creating a unique filesystem for my operating system, once I figure out how to write to the hard drive .
To answer your question. From what I have gathered, this might be completely incorrect, the requirements of a "file system" are really fairly simple. you need the following and maybe a little extra:
1. a way to keep track of files by name, size, and location.
2. a way to write to the disk
3. a way to read from the disk
the first is probably the hardest since I figure the other two are somewhat standard once you have a driver to interface with the disk.
I noticed in the floppy setup, that the only thing having anything to do with the FS was the BPB - Boot Parameter Block. That little tidbit of code or rather variables of a certain size is all an operating system needs to know what file system is employed by the disk. you could technically change this and build into your design os a way to read and write using your desired FS. It is just a table of values after all.
For instance say I wanted an FS named "StupidTestFS" I could define a standard in my OS drivers that only required a simple double byte identifier that just defined a bit pattern for my OS. say:
StupidTestFS db 0x3d4c // This is the only definition my FS needs
after that I would have to define a format in my OS to setup the disk. so I would have immediatly after the bootsector a table of n length that would define it's size in bytes with in the first byte. with a maximum of 255 bytes. with each byte making one file. not a lot of room for things but I am just making this up. Instead of file names I would have File numbers upto 127 and the second half of the byte would be the file length in sectors with a max of 127. then to find a file you would can the table one byte at a time looking for a match on the first half of the byte. when you find a match add up all the second halfs of the byte upto the point where you found the file you wanted. I would actually be doing this while searching. then move the disk forward to the sector matching the offest you added up from the end of the file table. read your file based on the length recorded in the table and viola you have your file and a crappy file system.
I know that is a bad example but it is the basic from what I gather. all the magic is defined in your FS driver and the simplest identifier would be something like a BPB where you define all the variables for your FS.
hope that helps
.To answer your question. From what I have gathered, this might be completely incorrect, the requirements of a "file system" are really fairly simple. you need the following and maybe a little extra:
1. a way to keep track of files by name, size, and location.
2. a way to write to the disk
3. a way to read from the disk
the first is probably the hardest since I figure the other two are somewhat standard once you have a driver to interface with the disk.
I noticed in the floppy setup, that the only thing having anything to do with the FS was the BPB - Boot Parameter Block. That little tidbit of code or rather variables of a certain size is all an operating system needs to know what file system is employed by the disk. you could technically change this and build into your design os a way to read and write using your desired FS. It is just a table of values after all.
For instance say I wanted an FS named "StupidTestFS" I could define a standard in my OS drivers that only required a simple double byte identifier that just defined a bit pattern for my OS. say:
StupidTestFS db 0x3d4c // This is the only definition my FS needs
after that I would have to define a format in my OS to setup the disk. so I would have immediatly after the bootsector a table of n length that would define it's size in bytes with in the first byte. with a maximum of 255 bytes. with each byte making one file. not a lot of room for things but I am just making this up. Instead of file names I would have File numbers upto 127 and the second half of the byte would be the file length in sectors with a max of 127. then to find a file you would can the table one byte at a time looking for a match on the first half of the byte. when you find a match add up all the second halfs of the byte upto the point where you found the file you wanted. I would actually be doing this while searching. then move the disk forward to the sector matching the offest you added up from the end of the file table. read your file based on the length recorded in the table and viola you have your file and a crappy file system.
I know that is a bad example but it is the basic from what I gather. all the magic is defined in your FS driver and the simplest identifier would be something like a BPB where you define all the variables for your FS.
hope that helps
There is only one reason to do anything. You enjoy it.