> Gerard Roudier wrote:
> >
> > On Sat, 12 Dec 1998, Linus Torvalds wrote:
> >
> > > So I want to be able to do things like frame capture (into a _file_, not a
> > > partition) etc, and there I think something like sendfile() is the answer
> > > (well, "copyfd()", whatever). And there I also think that we currently
> > > would do fairly badly on the write-out part due to the known problems with
> > > buffer cache behaviour under certain circumstances. But basically I still
> > > see absolutely no reason for supporting raw devices per se.
> >
> > You may forget Linux/Unix O/Ses legacies for just a minute and think of
> > the following:
> > Using Direct I/Os from user-land synchronously is indeed very bad for
> > streaming since everything will rely on disk write caching and prefetching
> > ability. But by combining direct IOs with an asynchonous I/O completion
> > mechanism, applications are able to implement kind of read-ahead and/or
> > write coalescence algorithms as needed.
> >
> > Just my 0,02 Euro which is a little more than 0.02$. ;-)
> >
> > Regards,
> > Gerard.
>
> indeed, this is just what databases such as oracle and informix like
> to do for maximum performance. remember, the oracle rdbms likes to
> think of itself as an operating system. it has a scheduler, a buffer
They stay in userland for portability issue and implement half an
operating system from user-land. I like this approach as I would like
a C compiler written in COBOL language.
> cache, i/o queues, multi-threading, etc. etc. the more of the o/s it
> can
> get out of the way (eg any kind of o/s level block buffering) the better
> the overall system performance will be. of course, it might be better
> if
Users pay all the system services overhead and O/S implementors are
trying to optimize their system for Oracle, so doing the work that
Oracle guys donnot want to do. Let oracle guy force users to use Java
and O/S guys will continue thinking of Oracle when implementing O/S
strategies and features in order to make Java faster ...
If I were an O/S guy I will feel me as an idiot.
> oracle just let the o/s do all the buffering, but a) it doesn't, and b)
> the o/s block replacement strategy probably isn't what a database would
> want anyway. hmmm...
A database which is entirely implemented in user-land is technically
a great crap in my opinion. I understand that for such a huge software
product portability requirements is much money spare, but when such
a product is so widely used, they it may happen that great stupidity
as using more that 32 bit address space on 32 bit systems will exist.
My post was indeed _not_ to encourage crappy things as data-base managers
entirely implemented from user-land.
Regards,
Gerard.
-
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/