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(a)fedoraproject.org>
>>> 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.
- Panu -