[arch-general] Patch for update-mime-info slowness
I am kind of annoyed by the time it takes to update the MIME database (something like two minutes on a recent i7 quad-core laptop). Until pacman has hooks/triggers, I have removed the calls to fdatasync (which are supposed to ensure that the files are truly written to disk). I prefer letting the system take care of it anyway, and I don't care much for consistency in desktop links and file associations. Y'know, it might bear the name "database", but it's not a database in the sense of a +1M row postgresql database). Anyone have an opinion on this? Am I a complete idiot in removing these calls to fdatasync? With this patch, updating takes around 5 seconds, haven't run it with a stopwatch yet. -- Sébastien Leblanc
On Wed, Dec 4, 2013 at 9:00 PM, Sébastien Leblanc <leblancsebas@gmail.com>wrote:
I hadn't noticed, but now I'm annoyed too :-(
Yeah, I think that this is kind of useless. If the files got corrupted, you can rebuild them running the command again. Maybe I'm losing something there, but it looks like the ext4-ate-my-data syndrome. With this patch, updating takes around 5 seconds, haven't run it with
a stopwatch yet.
Instead of a patch I've installed the libeatmydata package from the AUR and added a file /usr/local/bin/update-mime-database that calls `exec eatmydata update-mime-database "$@"`. Before: 21.618 s. After: 0.275 s. A x100 improvement, that's something! -- Rodrigo
[2013-12-04 15:00:31 -0500] Sébastien Leblanc:
I am kind of annoyed by the time it takes to update the MIME database
Please, please, please. Bug reports and feature requests go to: https://bugs.archlinux.org/ Not this list, not private emails to maintainers, not a combination of the above. This should really be clear to everyone by now... Starting now, I will reject any such emails submitted to this list and, if a whitelisted poster sends one, remove them from the whitelist. -- Gaetan
On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
I'm not sure whether this should classify as a bug report. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Lukas
On 5.12.2013 20:10, Lukas Jirkovsky wrote:
It's a "feature". It happened on 1.1 -> 1.2 upgrade, and I believe that this commit may be the culprit: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=b58fea97ee157951... You can try reverting it yourself and then rebuilding the package to see if this is the actual problem. If it is, I suggest you report bug to shared-mime-info maintainers (bugs.fd.o).
On 05/12/2013 20:10, Lukas Jirkovsky wrote:
How could this not qualify for a bug report? Maybe this should also be discussed upstream as this is not a Arch specific issue as far as I understand. Maybe they do have reasons for calling fsync so heavily.
Again, file a bug upstream. -- Timothée Ravier
On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
Thank you, I already know the URL to the bug tracker, but I was not looking to file a bug, or anything. I am only sharing a patch with fellow Arch users. Upstream already mentioned that this is their "expected" behavior (they wish to default to safety). https://bugs.freedesktop.org/show_bug.cgi?id=70366#c9 Thanks to Rodrigo, I now know the existence of 'libeatmydata'. -- Sébastien Leblanc
[2013-12-06 01:14:08 -0500] Sébastien Leblanc:
Then why did you Cc the maintainer of this package? I'm not insisting that bug reports and feature requests be submitted to our tracker just to make it harder for you guys to report them. It's in everybody's interest to do so: this way maintainers can actually track them. For instance, if a dev loses interest in a package and another one picks it up, they have the full history of what has been fixed and what is left to fix. We wouldn't force people to use the tracker if that wasn't more convenient for us. And from a users' perspective, bugs reported on the tracker are more likely to get fixed... -- Gaetan
On 06/12/13 05:39, Timothée Ravier wrote:
I have seen this bug filed upstream and rejected. It is a "feature"... For the same reason, I would frown on Arch patching it out. It is how upstream decided they want their software. Allan
On Thu, Dec 5, 2013 at 8:39 PM, Timothée Ravier <siosm99@gmail.com> wrote:
How could this not qualify for a bug report?
Because it may be an intended feature (and it looks so). In that case it's IMO better discuss it before filling bug reports, otherwise it often generates the "WONTFIX" kind of reports. However, discussing it in upstream ML would be more appropriate. Lukas
Yet another option is to fork shared-mime-info and upload an AUR package for the fork. If upstream WONTFIX an issue that several people perceive to be a bug, or WONTFIX a popular feature request, they should be aware that someone forking the project is a real possibility. Such are they perils and joys of open source software. - Alexander / xyproto
participants (8)
-
Alexander Rødseth
-
Allan McRae
-
Armin K.
-
Gaetan Bisson
-
Lukas Jirkovsky
-
Rodrigo Rivas
-
Sébastien Leblanc
-
Timothée Ravier