<p><a href="https://github.com/pmatilai" class="user-mention">@pmatilai</a> - I'm still looking for a good suggestion on where to read that macro and store it in a static variable.</p>
<p><a href="https://github.com/pmatilai" class="user-mention">@pmatilai</a> - I'm ok with fsync_periodically  or some such, it just means that if we ever want to change it, we have no way to do it nicely... we can't make a new <code>%_fsync_on_mb 50</code> with some sort of nice transition where people can move from one to the other. That's why I liked fsync_on_close, it's clear what it does, and when we want to implement something else we can. But I don't feel strongly, if you want it to be _fsync_aggressively or _fsync_periodically or something, let me know. However, it <em>should</em> have something about fsync in it so it's clear people don't want to do this on rotational media.</p>
<p><a href="https://github.com/n3npq" class="user-mention">@n3npq</a> - Yes, the slowdown is intolerable on rotational media. This is why its default off and an admin needs to make a smart choice. Like with mount-options, there's destructive options that are generally terrible, but we provide them for admins who need them. Like turning off ordered mode in ext4. :)</p>
<p><a href="https://github.com/n3npq" class="user-mention">@n3npq</a> - As you correctly characterized we're just slowing down RPM... giving more even access to IO... but to be clear we're not <em>just</em> slowing it down. There's other implications as well. For example we have some machines with 18 or 24 disks attached and installing a big RPM blows own the disk cache and causes <em>massive</em> IO load as the kernel sucks it all back in as the app continues doing it's work. By limiting the amount in the buffercache we don't evict diskcache. We can always afford the buffercache of a <em>single</em> file, but when Chef comes along and installed 25 RPMs with varying sizes of and numbers of files, we shoot ourselves in the foot. This is a different case than filling the IO buffers on our database systems where when MySQL comes along and and there's a huge queue of stuff to be flushed, and we cause stalls (the original incentive for this work). We actually played a lot with sync-on-write, sync-on-transaction, sync-on-close, and it turns out sync-on-close works incredibly well for a variety of different cases ... provided you're not on rotational media. I'm aware we could do more complex stuff... but it's a pretty hairy code-base and a simple solution that has shown to provide significant benefit seems like an easy win. Which is why I sat down with <a href="https://github.com/pmatilai" class="user-mention">@pmatilai</a> and others at DevConf.cz to discuss this work and that the approach would be acceptable before writing the patch.</p>
<p><a href="https://github.com/n3npq" class="user-mention">@n3npq</a> - yes, <a href="https://github.com/pmatilai" class="user-mention">@pmatilai</a>  also pointed out I shouldn't read the macros repeatedly, and said I should put it in a static variable, just haven't found a good place to do that, per above, still looking for a suggestion.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291959681">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb80w7xadwgX_hoJWot8cqak3kkYBH1ks5rs-KsgaJpZM4MyLOi">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb801RJDKIfoqen7v3Xt3PyZx4gqrJpks5rs-KsgaJpZM4MyLOi.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291959681"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jaymzh in #187: @pmatilai - I'm still looking for a good suggestion on where to read that macro and store it in a static variable.\r\n\r\n@pmatilai - I'm ok with fsync_periodically  or some such, it just means that if we ever want to change it, we have no way to do it nicely... we can't make a new `%_fsync_on_mb 50` with some sort of nice transition where people can move from one to the other. That's why I liked fsync_on_close, it's clear what it does, and when we want to implement something else we can. But I don't feel strongly, if you want it to be _fsync_aggressively or _fsync_periodically or something, let me know. However, it *should* have something about fsync in it so it's clear people don't want to do this on rotational media.\r\n\r\n@n3npq - Yes, the slowdown is intolerable on rotational media. This is why its default off and an admin needs to make a smart choice. Like with mount-options, there's destructive options that are generally terrible, but we provide them for admins who need them. Like turning off ordered mode in ext4. :)\r\n\r\n@n3npq - As you correctly characterized we're just slowing down RPM... giving more even access to IO... but to be clear we're not *just* slowing it down. There's other implications as well. For example we have some machines with 18 or 24 disks attached and installing a big RPM blows own the disk cache and causes *massive* IO load as the kernel sucks it all back in as the app continues doing it's work. By limiting the amount in the buffercache we don't evict diskcache. We can always afford the buffercache of a *single* file, but when Chef comes along and installed 25 RPMs with varying sizes of and numbers of files, we shoot ourselves in the foot. This is a different case than filling the IO buffers on our database systems where when MySQL comes along and and there's a huge queue of stuff to be flushed, and we cause stalls (the original incentive for this work). We actually played a lot with sync-on-write, sync-on-transaction, sync-on-close, and it turns out sync-on-close works incredibly well for a variety of different cases ... provided you're not on rotational media. I'm aware we could do more complex stuff... but it's a pretty hairy code-base and a simple solution that has shown to provide significant benefit seems like an easy win. Which is why I sat down with @pmatilai and others at DevConf.cz to discuss this work and that the approach would be acceptable before writing the patch.\r\n\r\n@n3npq - yes, @pmatilai  also pointed out I shouldn't read the macros repeatedly, and said I should put it in a static variable, just haven't found a good place to do that, per above, still looking for a suggestion."}],"action":{"name":"View Pull Request","url":"https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291959681"}}}</script>