Re: The old raw devices chestnut.

"Paul Watson" <paul_at_oninit.com> wrote in message news:407D3202.E6E8B0A4_at_oninit.com...

> > Absolutely not. Cache access is faster. And it has nothing to do
> > with fs or raw I/O. You get EXACTLY the same speed regardless
> > of where you got the data from.
> [cutting]
>
> But if the cache is too small or being turned over very quickly the
> cache will be slower 'cos you to copy from disk to cache and then
> copy from cache to the app.

Disagree. The cache access from a given db process will still be at the same speed: it's a memory-to-memory copy, the cache size means nothing in that context.

Of course, the db processes MAY have to wait for real I/O to fill up the cache. But that doesn't mean "the cache is slower".

> Interestingly on the bigger Sun servers the absolute bandwidth to
> disk is significantly larger than the bandwidth to memory so, in
> theory, you can the data from disk faster than from memory - I remain
> unconvinced:-)

Yup! :)
I'd guess what they mean is the overall *aggregate* I/O bandwidth is faster than memory access speed. This because in some of the 64 CPU boxes, it may actually be quite slower for a given CPU to access memory belonging to another CPU quad card. While the I/O speed stays the same as it goes directly to each quad CPU/memory card as requested.

Still, a strange claim by any standard. I've worked with a 64CPU ES10K Sun and its I/O speed for single disk access was nothing to write home about...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam