@pmatilai - I'm still looking for a good suggestion on where to read that macro
and store it in a static variable.
@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.
@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. :)
@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.
@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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291959681
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
