So what? That just tells you that you don't know everything: A lot of people
could show you how it is done reliably with of the shelf hardware and software.
> Since this problem is not raised in this thread yet :-)) IMO the only clear
> solution would be changes in ext2fs or may be special filesystem.
[...]
> > There is also the fact that raw io for databases IS faster. Whatever type
> > filesystem you design, doesn't matter since we know which blocks to write
> > where. An index entry points to a specific block/file/slot so its easy to
> > calculate the offset in the 'file' ;) And except for full table scans, the
> > data is spread allover the place, so read-ahead into buffercache doesn't do
> > didley squad in that case.
>
> But you still should keep track of space used for different tables in
> database :-)) This is EXACTLY filesystem work. Of course you could make
> internal filesystem in database but of course much more clear way is to
> fix/extend existing filesystem.
No it is not, ever heard of OS/400?
And in addition a filesystem can not do all the things databases would like
it to do unless the filesystem was specially tailored for the specific
database APPLICATION.
RAW DEVICES are simply a short cut of the system to allow databases to use
"filesystems" specially tailored for the specific application (the on site
application, not the database as distributed by the vendor). Not more and not
less. So why don't they use the VFS API provided by most (but not all!)
systems? Simple: because this makes the database system-dependant and
unnecessary complex. And complexity kills software.
Above you were stating that special filesystems would be the solutions
to the problem. They are and the only system independant way to do this are
raw devices.
Yours,
Dominik Kubla
-- The text above represents my personal opinion and does not represent the official position of my employer on the issue(s) discussed. Any official statement by me on behalf of my employer will be marked as such.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/