Re: Raw I/O vs files (was Re: Raw partitions / cooked files)

In a recent append, lparsons_at_exlog.com (Lee Parsons) writes...
>I would argue that if you need the performance increase bad enough to
>start changing the filesystem code, you have no excuse not to skip it
>and go directly raw.

Perhaps I was unclear. I usually am :) What I meant was that implementing a storage architecture using raw I/O is a lot like implementing a specialized file system. My questions are about the possibilities of getting higher performance because of many things one might choose to do which general purpose OS file systems don't do. For example: huge block size, large sequential prefetch, shorter read/write pathlength etc.

>database. There are a ton of good reasons for using cooked database files
>but if your system is REALLY being impacted by the cost of running
>that filesystem code then the answer it to get it out of the way
>not improve it. If you need the very small perf increase gained by
>running a non-standard fs then you need the increase gained by not
>running the fs at all.

And this is what I am curious about. What are the "small" perf gains? Are they worth the expense of avoiding the filesystem altogether?

>I think that is because you, I and everybody else already know the
>answer. The only way your are going to see a *significantly* faster
>raw benchmark is if something else somewhere is not tuned well.

I don't necessarily think this is true. If you look at the TPC-A/B/C benchamrks, all the leaders get their numbers using raw I/O. This implies raw I/O can be faster when tuned. Without actually doing a huge benchmark comparison, I would be curious to know what others have observed.

How many DBAs are running Oracle/Informix/etc etc using raw I/O? Any?

>Before I get flamed I should say there are cases where going raw is
>the thing to do, but those cases are rare and usually in situations
>where doing the Right thing is not an option.

No flaming, just old fashioned curiousity.

Pat Gainer
gainer_at_almaden.ibm.com Received on Wed Jul 28 1993 - 18:07:22 CEST