On 6/3/20 10:18 AM, Panu Matilainen wrote:
On 6/3/20 9:27 AM, Adam Williamson wrote:
On Wed, 2020-06-03 at 09:06 +0300, Panu Matilainen wrote:
On 6/2/20 7:25 PM, Adam Williamson wrote:
On Tue, 2020-06-02 at 11:05 -0500, Richard Shaw wrote:
On Tue, Jun 2, 2020 at 10:25 AM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx>
wrote:
On Tue, 2020-06-02 at 06:34 -0500, Richard Shaw wrote:
boost-devel, nosync=False, bootstrap=True
real 1m13.294s
user 0m6.723s
sys 0m2.761s
---
So it looks like boostrap=True and nosync=False is the culprit,
which I
inadvertantly got myself into. I did have either set and of
course nosync
would be False by default and it looks like bootstrap=True by
default for
rawhide.
When you say 'bootstrap', which setting do you mean exactly? I don't
see one that's just called 'bootstrap', I see --(no-)bootstrap-chroot
and --(no-|use-)bootstrap-image .
$ cat .config/mock.cfg
config_opts['cleanup_on_failure'] = False
config_opts['nosync'] = True
config_opts['use_bootstrap'] = False
I got this from the documentation, maybe should have searched a bit
more,
didn't think there was more than one bootstrap option.
That seems to be the same as --bootstrap-chroot , i.e. --no-bootstrap-
chroot should set it False.
So, if I explicitly set nosync = True in mock.cfg it goes back to being
as fast as I remember. But that's somewhat odd, because:
a) I definitely didn't have explicit config to turn nosync on before
b) I didn't actually have the nosync packages installed at all until
after I hit this problem
so it seems like somehow before I was getting fast performance without
using nosync, but now I need it? Weird...
Okay, that's useful. I'm not at all familiar with how this all actually
works in mock but I see that nosync.so is being copied around etc, and
with bootstrap introducing an extra layer in between, it's not hard to
imagine a subtle bug or two in there. Just a guess though.
The thing is, I'm really pretty sure I *wasn't using* mock's nosync
support before. I don't see how I could have been, since I didn't have
nosync installed.
Ah, sorry I misunderstood that a bit originally.
So this still seems kinda mysterious. Either somehow
it wasn't fsync'ing before but it is now, or somehow disk writing
performance on my system fell off a cliff?
I'll try and poke it some more tomorrow if I can, try some old kernels
and/or old mock builds or something.
Found it.
Nothing to do with databases, it's the new automatic SSD detection which
also enables _flush_io to fsync files as we go during transactions. It
does this on the grounds that it's good for the system otherwise (avoids
trashing the caches and io peaks) and that it's not prohibitively
expensive on SSD, but I guess this here quite clearly shows that it
actually is.
Will fix shortly.
Okay, fixed in rpm-4.16.0-0.beta1.2 in rawhide.
For it to take effect though, the bootstrap-root needs to be updated (or
recreated). I don't know whether mock updates that automatically and if
it does, under what circumstances.
That's also how this all relates to the bootstrap stuff:
When using mock without bootstrap, host rpm config is used. On Fedora <
33 hosts, rpm doesn't automatically enable the io-flushing so things are
fast if not using bootstrap, or building for F < 33. And OTOH if running
from a rawhide host things would be slow unless you were building for F
< 33 with a bootstrap.
And that's also why you didn't need nosync before but suddenly it makes
a huge difference.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
