Filesytem, cool thing I just realized about mine.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Anyway, I just thought I'd let everybody know. The RWFS filesystem that I've been working on, apparently can handle 536862719.75000381 exabytes of disk space at on one partition! Simply by using the computers ability to calculate, instead of listing. Anyway, it's not done yet but I thought it was pretty cool.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

First of all, instead of trying to manage the whole hard disk as just a series of blocks. I decided to split it into even larger divisions called block sections. These sections have no characteristics other than number, and files can stretch across any number of block sections. They are really only used to calculate logical addresses. I'm kinda stuck for time right now so more later...

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Also, it uses 32 bit multiplication to represent id's and blocks and such. So It's main limitation is what the operating system is willing to calculate 64 bit 128 bit etc.

EDIT:

Code:

/*Copyright (C) Kristian Hart 2009

typedef struct
{
    unsigned short version_id; //allow for reading different versions of the filesystem
    unsigned short system_id;//id that an operating system can use to know what os the filesystem originated on
    unsigned short m_ownerid;//the id of the person who is admin of the filesystem
    unsigned short sector_size;// size of a sector in bytes
    unsigned short  blocksize;//the size of a block in the fs in number of sectors
    unsigned int   blocksections;//number of block sections
    unsigned int   num_file_entry_blocks;
}FS_DESCRIPTOR;//structure that defines a filesystems characteristics

typedef struct
{
    unsigned int idbase;//directory id base
    unsigned int idcalc;// a number to multiply the idbase by to get the actual id(usually 1 on small trees)
    unsigned int parent_idbase;
    unsigned int parent_idcalc;
    char         name[20];
}DS_DENTRY;//defines an entry in the directory tree

typedef struct
{
    unsigned int blocksection;
    unsigned int blockstart;// start block
    unsigned int blocks;//consecutive blocks in the array entry
}BLOCK_ARRAY_ENTRY;//enty in a list of blocks

typedef struct
{
    unsigned char system;//bits the system uses for characteristics
    char name[20];
    unsigned int parent_idbase;//id base of the parent folder
    unsigned int parent_idcalc;//id calc of the parent folder
    unsigned int num_barray_blks;// number of block entry array blocks (they are always consecutive)
    unsigned int blocksection;//the blocksection the array is in
    unsigned int blockstart;//first block in the array
}FD_ENTRY;//file descriptor entry

This should give you an idea of how it works. The filesytem is designed so that information is really only given as needed to find the files.

EDIT 2:
I think I've gotten into the habit of extreme commenting.... :twisted:

overburn · **Joined:** Sun Feb 22, 2009 9:15 am **Posts:** 50

happens to all of us at some point :lol:

btw where can i find some tutorial for a barebone filesystem that i can build on?

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

I've almost got a disk image program for it working.

I wonder, has anyone used this technique to allow this much storage so far?

Troy Martin · **Posted:** Thu Feb 26, 2009 9:53 am

I might like to implement it for floppy storage in TBOS now that I've read over some existing FAT12 code.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Wondering, would an article about this particular filesystem be wanted for the wiki? At least, once I get my kernel to boot from it.

imate900 · **Joined:** Sat Feb 28, 2009 11:43 am **Posts:** 80

Using it in my OS!

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Use it as you like, I only ask that you make mention of me in your OS design or code.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Not to advertise my os (as it is only just starting), but the design for the fs (the layout that is) is at http://code.google.com/p/leviathanv/ in the wiki.

EDIT: It's not complete but it will give you an idea of how the fs is a arranged.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Actually I'm rethinking that. Wondering, around what percent of sectors are usually bad?
EDIT: If it's a relatively small amount, I can just list bad sectors in a table.

JohnnyTheDon · **Posted:** Mon Mar 02, 2009 9:09 am

Wikipedia agrees:

[quote=Wikipedia]A modern hard drive comes with many spare sectors. When a sector is found to be bad by the firmware of a disk controller, the disk controller remaps the logical sector to a different physical sector.[/quote]

So I wouldn't worry about bad sectors. You'll probably end up blacklisting sectors that the firmware later remaps and repairs.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

Ah, the reason I was worrying about bad sectors was that Tanenbaum's book says that not all hard disks do that. So I'm cutting that section out of the filesystem.

nekros · **Joined:** Wed Mar 05, 2008 9:10 pm **Posts:** 391

I have now the fully revised version 1 of the RWFS filesystem. Check the wiki at http://code.google.com/p/leviathanv/wiki/RWFS for the updated structures(Really only one small addition to the FS_DESCRIPTOR structure). I added an entry for allocating free blocks.

EDIT: Once, I have the filesystem implemented in an image program and have my kernel booting, I'll try to add a complete article on implementing it in the OSDEV wiki.

Troy Martin · **Posted:** Mon Mar 02, 2009 9:58 pm

nekros wrote:

Once, I have the filesystem implemented in an image program and have my kernel booting, I'll try to add a complete article on implementing it in the OSDEV wiki.

Please do, and if possible, make the source for the image program available so we can compile it and simplify making images with the FS onboard

OSDev.org

Filesytem, cool thing I just realized about mine.

Who is online