guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#58035] sync-before-registering is false, possibly the cause of empt


From: Maxime Devos
Subject: [bug#58035] sync-before-registering is false, possibly the cause of empty files in the store
Date: Wed, 5 Oct 2022 09:58:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0



On 04-10-2022 23:49, Ludovic Courtès wrote:
Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

'sync' seems relatively inexpensive to me, compared to the time
required for building a package and even more inexpensive compared to
the cost of debugging store corruption:

That’s not a fair comparison.  :-)

Possibly, openjdk is a bit of an extreme case.

Imagine, you run reconfigure/upgrade;
that downloads tens to hundreds of store items.  Calling sync(2) after
each item may be hardly noticeably on an SSD, but I bet it’s going to be
super expensive on an HDD.  (In the syslogd case, each fsync(2) call—not
even sync(2)—would cause pauses of several 100s of ms.)

If after some testing, this turns out to be a problem, there are some options to avoid this (see: the delaying 'fsync' of the previous response).

Maybe a good test would be to run a daemon on an “average” HDD with
sync-before-registering = true and to run ‘perf timechart record’ while
it’s fetching a large number of substitutes.  That way we’d have
concrete data to talk about.

Any takers?  :-)

I don't have a HDD to test sync-before-registering=true with.

Greetings,
Maxime.

Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]