OSDev.org

Hi all
If my file system design like these, any problem?

1) everthing is not linked to everything, eg. directory is not linked to file. If you want to read a file, just use a hash function to hash the file path with the content offset, it will return a LBA to you, then you can use this LBA number to read fom the harddisk

if i want to read a file, with a offset 1000, here is the pousedo code:

int lba=hash('/path/to/file', 1000)
char *a=read(lba)

2) if you want to ls a directory, just hash the directory path and get the LBA number, read the directory block, and it will tell you how many file are in that directory

advantage of this design:
1) no need to lookup where is the file located on the harddisk
2) easy to implement, *only i guess*


thanks
from Peter ([email protected])
http://pos.petersoft.com
http://www.KingOfCoders.com[/url]

That will only work as long as you don't get collisions. It also wastes a lot of space and you will have to limit the file size to a very small size (otherwise you won't be able to store many files on the disk as you will get many collisions).
It's not a very good idea; try implementing fat32 or ext2 first.

Proper filesystem design is rather advanced stuff - since you apparently don't know what a hash really does, I don't think you're ready for a design of your own.

This does not sound good.Read documentation about filesystems.
PS I dont recommend starting a FAT driver like many do.

I dont recommend starting a FAT driver like many do.

Why not? Once I had my VFS up and running, I got GRUB to load a FAT disk image in to RAM as a module and wrote a driver for it (read only to start with). This gave me a pretty easy way to make sure that the concepts behind a 'real world' file system fitted in to my VFS nicely. Pretty easy too. Of course, you can then add Ext2, SFS and so on.

I would suggest that the best way to go about things is to write a driver, fitting it in to your VFS, using an existing specification. Have a look at the File Systems page on the wiki for some background.

Cheers,
Adam

FAT ,specially FAT12 and FAT16 is easy to code and put in place.
I think its the only good thing those guys at microsoft ever did in their entire life .

FAT ,specially FAT12 and FAT16 is easy to code and put in place.
I think its the only good thing those guys at microsoft ever did in their entire life .

Are you kidding me? FAT was okayish in the 80's, when they didn't really need all the fancy features that modern filesystems have.

But then they kept adding more features, which the original design really wasn't suited for (directories, long/Unicode file names, extended attributes). And it still faces problems like fragmentation and such...

@OP: Apart from the obvious hash problem, you'd also experience dramatic slowdowns when performing operations on directories, since you'd have to manually unhash each file in the ENTIRE FILESYSTEM to see if it was part of that directory. Not a good idea. Even FAT is better than that.

After all that, I still advise implementing FAT support first .