[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Has something changed with RPMS?
From:       Panu Matilainen <pmatilai () redhat ! com>
Date:       2020-06-03 7:18:25
Message-ID: 11d5ea07-4bcc-896f-290a-1ee39f0c4553 () redhat ! com
[Download RAW message or body]

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@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 -
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]