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
