Results 1 to 1 of 1
Thread: File System
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jul 2005
I have what i believe to be some very tough questions for you gurus out there; However, I would like some feedback from any and everyone on: concepts, design model, hints, and any other suggestions.
With all the talk about database file systems and how great they are I decided that I would try and build one (or at the very least get one started so the specialists can work on it). This will be a true database structure meaning no folders/directories at all!
This is not the dbfs that all of you have been hearing about. DBFS, was made as a file system placed on top the the existing file systems. This was done in the authors mind to support backwards compatibility. I believe this concept has been proved through history to hurt the computing industry more than help it. Besides all that, its simply an extra layer that you would have to deal with and your system will suffer for it.
OK now to the fun stuff:
As a lot of you know the basic setup of a device (Hard Drive) has been traditionally broken up as follows:
Boot Block: This is a single block at the beginning of the device reserved for booting the computer.
Super Block: This is basic information about your file system, so computers can recognize and use it.
Inode map: This is a bitmap which indicates what inodes are free for use and which ones are in use.
Datablock map: This is similar to the inode map, only it indicates which datablocks are free and which ones are in use
Inodes: This is a series of blocks that store the actual inodes. Since a inode doesn't take up an entire block we only need a couple of blocks to store all the inodes
Data blocks: These are the actual data for files
More advanced file systems that handle very large files wont just point to the file block, but to a block or series of blocks that breaks down ALL the blocks that belong to a file
What i purpose:
I would like to break down the MySQL program using it as our shell, replacing the bash prompt (which would be completely obsolete in the event folders no longer existed) Our new shell controls and breaks down our device through relationship tables and files stored at the beginning of the device.
My First Problem:
Although i have made a few programs of such in the past, I like many others have never had the task of ACTUALLY using the data on my devices. We always just push a save button and the driver written for the operating system decides where and how to save the data on the media in question. What "C" commands are available for managing random access media devices? Obviously I'm dealing with pointers, but I cant find information on this anywhere. (Kind of upsets me, as we have a billion sites dedicated to talking to the processor and almost none for talking to other devices)
Problem two: Cant write data to a device without it being mounted by the operating system. System wont mount a media without knowing the file system, so i couldnt write the data to it if i wanted to. This implies that i have to make the driver/module for reading the file system AND make the format tool to format the device before i ever get to work on the device. There must be commands for dealing with this, such as FORCE a mount not knowing the file system.