----- Original Message -----
From: "Dan Nelson" <dnelson@stripped>
To: "Harald Fuchs" <hf@stripped>
Cc: <mysql@stripped>; <Heikki.Tuuri@stripped>
Sent: Wednesday, August 28, 2002 6:10 PM
Subject: Re: MySQL/InnoDB-4.0.3 is released
> In the last episode (Aug 28), Harald Fuchs said:
> > I think there's something missing in the changelog. About a month
> > ago, someone named Christian Jaeger from ETH Zurich asked about
> > unbuffered raw device support for Linux. You replied immediately
> > with two sets of patches for 3.23.x (regaring unaligned access) which
> > apparently fixed the problems, for Mr. Jaeger at least. When I tried
> > to apply those patches to 4.0.2, I still got operating system error
> > #22. Thus I decided to wait for 4.0.3.
> On a similar topic, many OSes support "Direct I/O" on files, which
> causes reads and writes to bypass the system's buffer cache. It's
> usually enabled by adding the O_DIRECT (or O_DIRECTIO) flag to your
> open() call. From a quick Google search, FreeBSD and IRIX use
> O_DIRECT, Tru64 uses O_DIRECTIO, and Solaris has you call a directio()
> function on the file descriptor after you open the file.
this may come some time in future. It is just a small change to
innodb_flush_method in my.cnf.
I am cautious to use O_DIRECT on Unixes. There is evidence that fdatasync()
corrupted files both in Linux and Solaris. That is why also the InnoDB flush
method O_DSYNC is currently internally mapped to normal O_SYNC.
Thus the problem in these nonstandard file i/o methods is that they often
seem to be buggy. But giving users the option to test these would be good.
> Adding this should really help performance on large InnoDB tablespaces,
> and keeps you from having to fall back to raw partitions for unbuffered
> IO, which are a pain to manage.
> Dan Sql Query Nelson