Re: Unix filesystem: use buffered IO or direct IO?

I fel like a complete fossil now. I've been using Raw I/O for years and have had great results. No VXFS, volume managers, or anything else in the way, just me and

c1t0d1s0

et al

(well of course not ...s0, that must be owned by root and unwritable to anyone).
(and s6, and... well okay. yeah it isn't easy, but it is hardly rocket science)

Well, okay, so I don't get fancy GUI screens, and "would you like nutmeg on your cappucino while we build your partitions?"/

But I do get performance.
I have loathed Oracle's doubletalk for years over the matter of Raw partitions.

RSH. "Michael Brown" <mlbrown_at_apps-dba.net> wrote in message news:qq4bcusa3bos2nr0ichgl6sm5uher4i5u3_at_4ax.com...
> On 23 Apr 2002 15:10:03 GMT, chao_ping <chao_ping_at_163.com> wrote:
>
> >Since some unix filesystem like sun ufs and veritas vxfs now support
> >direct I/O, from steve adams's site, it seems that using direct I/O is
> >better than use buffered I/O. For example, i have a system like: 8CPU/8G
> >mem/2 T3 Raid5/Veritas VXFS. This is an OLTP system, most wait event is
> >db file sequential read. Which option shall i use? use direct I/O, or
> >just general buffered I/O?Any one have some experience? And if using
> >Quick I/O, since it act like raw device,How much memory shall i leave
> >for the filesystem buffer ?
> db file sequential read is either random single block reads or
> transfers from the TEMP tablespace during a sort. The TEMP tablespace
> I/O might benefit from buffering, but odds are the random single block
> reads won't see any benefit from system buffers assuming that your
> raid hardware has a write cache (writes to RAID 5 require at least 4
> i/o operations). If you do not have a write cache, you need to leave
> the system buffer cache on. Otherwise, switch to direct i/o, if you
> notice a slow down in sorts that have to go to disk, turn the buffers
> back on for the temp tablespace (if it is on a seperate file system)
> or consider increasing your sort area size (which implies rebuilding
> your TEMP tablespace to keep the extent size appropriate).
Received on Thu Apr 25 2002 - 05:19:49 CDT