Every OS I've seen has their own file system.  There is a movement in the corporate industry, from certain companies, that the Database is the ultimate file system, and as such should be used as the OS's file system.  Every file system is essentially a database, but not one that is expandable for extra attributes and information.  In traditional OS design, once the FS is designed it is unchangeable and must be used for the life of the system.  This causes problems when the need arises for more information to be stored with a file or you need to implement features such as compression or encryption. 

The Database FS would allow maximum flexibility.  The database back end would probably be chosen from some currently existing technologies, as there are some very stable and usable database formats which are available (unless they are gonna charge for it). This also brings out the idea of keeping OS, applications, configuration, and user profiles in different databases to have excellent organization, and
distribution control. Some example applications of this FS would be remote connectivity security, very powerful scripting, and specialized programs (and even databases! :). 

One  issue with this type of system is speed.  Database level transactions tend to be slower than typical FS transactions due to the addition of recovery information and extra data tags, and possibly out of alignment data. To recover from this, the database system must be able to provide physical hardware addresses for programs to read/write data to. The database program should be  able to provide this info without slowing down the application, and hopefully not taking up much extra system memory. 

The next question is how do we store these databases on the storage devices.  A simplified database readable on boot  would be used to find the appropriate information and continue with the rest of the bootup. 

I'd like some feedback on this document, as I think I went a little too complicated on what seemed like a simple subject...