Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco <recoverym4n@enotuniq.net>]

	Hi.

On Thu, Jun 18, 2020 at 08:57:48AM -0400, Michael Stone wrote:
> On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote:
> > On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote:
> > > On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> > > > Long story short, if you need a primitive I/O benchmark, you're better
> > > > with both dsync and nocache.
> > > 
> > > Not unless that's your actual workload, IMO. Almost nothing does sync i/o;
> > 
> > Almost everything does (see my previous e-mails). No everything does it
> > with O_DSYNC, that's true.
> 
> You're not using the words like most people use them, which does certainly confuse the conversation.

Earlier this thread someone posted a link to Wikipedia article on the
matter. Whatever terminology I'm using is consistent with it.
Qualifies for "common terminology" IMO.


> > Although if it uses sqlite - chances are it does it with O_DSYNC.
> 
> That may be true in some modes but not in my quick testing and wouldn't be what I'd expect.

Every time I have to use yum(1) or dnf(1) I have to suffer because of it.
Luckily Debian uses apt(1) which miles ahead of them both in this
regard (dpkg(1) fdatasync on each file is a different story).


> writing one block at a time is *really* *really* bad for performance.

True. But also it's good for the integrity of written data, which is why
(presumably) sqlite upstream did it.


> Most applications for which I/O performance is important allow writes to buffer, then
> flush the buffers as needed for data integrity.

No objections here. Most applications write their files as a whole, it
makes total sense to do it this way. But there are exceptions to this
rule, and if it modifies its files piecewise, it probably uses O_DSYNC
to be sure.


> Also note the subtlety of "synchronized" I/O vs "synchronous" I/O
> which is another thing that's really important in some contexts, but
> will just make what should be a simple answer more confusing if you
> follow the rabbit hole.

Duly noted.


> > > simply using conv=fdatasync to make sure that the cache is flushed before exiting
> > > is going to be more representative.
> > 
> > If you're answering the question "how fast is my programs are going to
> > write there" - sure. If you're answering the question "how fast my
> > drive(s) actually is(are)" - nope, you need O_DSYNC.
> 
> While OF COURSE the question people want answered is "how fast is my programs are going to write there"

But the most important hidden question here - which programs?
That ones that write their files by one big chunk (which is common) or
the ones that do it one piece at a time (any RDBMS, for instance)?


> rather than some other number like "how fast is some mode of writing that I won't use",

Or rather - I won't usually use.
Ever wondered why Firefox gets sluggish if OS is I/O bound? Periodic
updates of sqlite databases with O_DSYNC, that's why.


I propose to leave it here as it is.

Reco