DK> So what? That just tells you that you don't know everything: A lot of people
DK> could show you how it is done reliably with of the shelf hardware and software.
"Specially designed hardware" != "not shelf hardware" :-) BTW hardware part is
more flexible here then software part ...
>> 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.
DK> [...]
>> > 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.
DK> No it is not, ever heard of OS/400?
Of course. There are database as core of the system. *nix is not designed this
way. Both designs has benefits but analogy: both swiss roll and stockfish
are nice food while swiss roll with stockfish is ...
DK> And in addition a filesystem can not do all the things databases would like
DK> it to do unless the filesystem was specially tailored for the specific
DK> database APPLICATION.
DK> RAW DEVICES are simply a short cut of the system to allow databases to use
DK> "filesystems" specially tailored for the specific application (the on site
DK> application, not the database as distributed by the vendor). Not more and not
DK> less. So why don't they use the VFS API provided by most (but not all!)
DK> systems? Simple: because this makes the database system-dependant and
DK> unnecessary complex. And complexity kills software.
Exactly. And raw devices support makes kernel unnecessary complex and (even more
important!) much more flexible. "And complexity kills software" :-)) And since
this is not needed by 99% (more like 99.99% :-) of users mainstream kernel will
not include raw devices support :-))
DK> Above you were stating that special filesystems would be the solutions
DK> to the problem. They are and the only system independant way to do this are
DK> raw devices.
Create module for raw access. Create special filesystem (better way IMO). Do not
pollute mainstream kernel with stuff needed by only 1% (more like 0.01%) of
users just as "temporary solution". Linux is not Solaris or HP-UX: it could be
tweacked as needed and when needed.
-
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/