Description of problem: The update-mime-database program in f20 takes about 20 minutes to run on my system. Judging from https://bugs.freedesktop.org/show_bug.cgi?id=70366 the reason is that it deliberately turns on synchronous disc I/O. This is absurd and ridiculous. Why should this one program consider itself so important that it must sync all I/O? If corruption due to not syncing is such a problem, shouldn't the entire system be switched to always use sync I/O? To top off the absurdity, the mime database is one of the most incredibly unimportant bits of data on the system. Even if it got corrupted, you could re-run update-mime-database to fix it. Why does it need to slow down by a factor of about 30 to protect unimportant data when nothing else on the system feels that linux disk I/O is so unreliable that other things need the same treatment? Please change the rpm build script for this to export ac_cv_func_fdatasync=no Version-Release number of selected component (if applicable): shared-mime-info-1.2-1.fc20.x86_64 How reproducible: Every time I run a yum update, it spends 20 minutes grinding the disk just before the verify step of yum. Steps to Reproduce: 1.yum update 2.watch cleanup take forever 3. Actual results: Dog slow Expected results: Speed it used to have before this change Additional info:
In addition - upgrade to f20 takes ages because of this... Please, the fix/workaround is so simple...
What happens between the cleanup phase and the verification phase is egregious. The pause is lengthy, it is unexplained, and the disc is made to work furiously.
20 minutes ago my disk started grinding at the end of this morning's yum update. It is still grinding and there is no indication it will ever stop. I'm begging you! Please fix this monstrosity!
Let's assume, for the sake of discussion, that there truly is a good reason to use synchronous I/O. The fact remains that, in between the second stage (clean-up) and the alleged third stage, there is an unacknowledge stage that takes a very long time and entails a signficant amount of disc activity. A great many users will think that things have gone very wrong, and will respond by shutting down. At the very least, users need to be told that this stage is part of the process. And all that it take to do this is one line of output to the console. The assignee, Bastien Nocera, has time to pirouette in his 'blog and on varioous social media, but apparently no time to code for that one line of output to the console. So be it. Would it be possible to get a different assignee, with different priorities?
I'm hitting this horribly too at our site starting to do wide f20 deployments, I'll see about moving this along. Bastian's upstream comment: "The correct way to fix this is for your system not to run update-mime-database for each package, put for the whole set instead ("triggers")." Unfortunately, doesn't mesh with fedora's current packaging guidelines, https://fedoraproject.org/wiki/Packaging:ScriptletSnippets?rd=Packaging/ScriptletSnippets#mimeinfo As far as I'm aware, update-mime-database currently doesn't have smarts like gtk-update-icon-cache to know when it's cache is current or not, to take advantage of any %posttrans optimization to run only once per transaction , like: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets?rd=Packaging/ScriptletSnippets#Icon_Cache Please correct me if I'm wrong, and I'll gladly work to get the guidelines amended to take advantage of it. If correct, it would benefit greatly if update-mime-database did have some mechanism like this (for example, similar to icon cache and checking timetstamp of /usr/share/mime) Lacking any mechanism for the aforementioned issue, I'll lobby to implement something like the initial suggestions in this bug to restore reasonable performance.
Just so we have some numbers here (and not just in the upstream bug)... On my oldish ~6 yr-old laptop: fedora stock update-mime-database call time: ~34 seconds rebuild without fdatasync u-m-d call time: ~0.7 seconds Now, imagine rpm transactions that include 5, 10, 20 (or more) such calls. :(
On my system at work where the disk sounds like it is being tortured for several minutes at a time, I can't believe it is good for the long term health of the disk either. I've seriously considered adding a system wide LD_PRELOAD environment variable to override fdatasync() so it is a no-op, but the thought that there might be some legitimate use for the call has stopped me.
Colin, what do you think per my proposed way forward in comment #5 ?
All my opinions are in the upstream https://bugs.freedesktop.org/show_bug.cgi?id=70366
The only comment I see is that you'd support some environment variable to turn the sync off, via something like PKGSYSTEM_DISABLE_FSYNC=1 That doesn't help fix this in fedora 20. I'm advocating reverting the sync requirement now, until something better comes along.
shared-mime-info-1.2-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/shared-mime-info-1.2-4.fc20
This test build enables support for PKGSYSTEM_ENABLE_FSYNC environment variable to opt-in to the new safer (but slower) writes as suggested in https://bugs.freedesktop.org/show_bug.cgi?id=70366#c19
Package shared-mime-info-1.2-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing shared-mime-info-1.2-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6601/shared-mime-info-1.2-4.fc20 then log in and leave karma (feedback).
Update: Bastien "fixed" the upstream bug report by making PKGSYSTEM_ENABLE_FSYNC opt-out and default on, which doesn't help our use-case here. I guess I'll adapt the patch to the upstream implementation, except flip the default off instead.
(In reply to Rex Dieter from comment #14) > Update: Bastien "fixed" the upstream bug report by making > PKGSYSTEM_ENABLE_FSYNC opt-out and default on, which doesn't help our > use-case here. > > I guess I'll adapt the patch to the upstream implementation, except flip the > default off instead. Don't. Make rpm/yum/whatever take their responsibility and use the envvar.
Or just add a system wide /etc/profile file to the package that sets the envvar.
I understand your point of view Bastien, but I respectfully disagree. I would argue if you want that approach, fixing rpm/yum/whatever is a *prerequisite* to (re)enabling fdatasync by default. Fixing the performance regression is more important.
I've revoked https://admin.fedoraproject.org/updates/FEDORA-2014-6601 for now to respect your formal opposition. Would you be open to me asking FESCo to arbitrate?
(In reply to Rex Dieter from comment #18) > I've revoked > https://admin.fedoraproject.org/updates/FEDORA-2014-6601 > for now to respect your formal opposition. > > Would you be open to me asking FESCo to arbitrate? I'll drop Fedora maintainership of this package if I have to justify myself again. I've already done so as the upstream maintainer.
I'm sorry you feel that way. I do continue to feel strongly about this bug, however, and we do still have an impasse and difference of opinions. I will likely move forward with asking FESCo to look at this. I'll be happy to help maintain this package in fedora moving forward, if you feel you cannot or do not want to continue doing so.
Fyi, https://fedorahosted.org/fesco/ticket/1318 please add your opinion, especially if you feel I mischaracterized matters in any way.
I'm with Rex Dieter, the performance impact of the fdatasync is way too high here to enable it by default, at least at this time. Thus, it ought to be disabled by default (at least for now).
Or removed completely. I can't understand why 99.9999999% of all apps are perfectly able to write to disk without using fdatasync yet somehow the mime database creation tool deems it absolutely essential? The heck with performance being more important (which it is), why should fdatasync ever be involved for any reason? I can't begin to imagine any reason for it.
fdatasync was involved after real-world problems were observed. I very much doubt that this is the place to revisit that decision, especially as there are multiple ways of mitigating the problem that so provokes us here, without such a revisitation.
Do you have any details about these real-world problems? Lacking such details... Given that this output can be regenerated easily in < 1 second, I find fdatasync to be a great over-reaction...
It's an over-reaction _here_. And no one seems actually to dispute that it's an over-reaction here -- M. Nocera simply seems to feel that an extended period of suffering will, uhm, build character? amongst Fedora users -- so I'm not going to dig into that history. If you feel that the problem is _deeper_, then a more general bug report needs to be opened.
FESCo decided in today's meeting not to override the default behavior here, https://fedorahosted.org/fesco/ticket/1318 So, I'll prepare an update to comply with that policy decision.
shared-mime-info-1.2-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/shared-mime-info-1.2-7.fc20
According to the FESCo ticket, FESCo decided *not to require* overriding the default behavior, which is different from *requiring to not* override it.
In some other context, that distinction would be very important; but, in this context, proceeding as if FESCo has green-lighted an over-ride would lead mostly to heartache.
So, since I can't actually interpret all the double negatives here, can anyone tell me what system wide environment variable I want set to which value at all times to make sure this idiocy doesn't ever call fdatasync?
Explicitly setting env var PKGSYSTEM_ENABLE_FSYNC=0 will disable it.
Package shared-mime-info-1.2-7.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing shared-mime-info-1.2-7.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8002/shared-mime-info-1.2-7.fc20 then log in and leave karma (feedback).
BTW: without explicit "nobarrier" on a otherwise hyperfast ext4 RAID10 this problem exists, mounting rootfs with "nobarrier" and the hammering on the disks goes away (it took long to realize that filesystem barrieres on the only machine without a UPS is the reason for the big difference)
Thanks for this fix (now I can stop building shared-mime-info locally). FWIW, if you're using sudo with yum you'll need to explicitly set that env var on the cli: sudo PKGSYSTEM_ENABLE_FSYNC=0 yum install foo just setting the env var in /ec/profile.d/* doesn't affect sudo.
Or you can add that env var to the env_keep setting in /etc/sudoers: tomh> sudo printenv | fgrep SYNC PKGSYSTEM_ENABLE_FSYNC=0 Ta-Da!
shared-mime-info-1.2-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1124021 has been marked as a duplicate of this bug. ***
This bug is back in Fedora 23. Using DNF for system updates. [root@metallica ~]# rpm -q shared-mime-info shared-mime-info-1.5-2.fc23.x86_64 [root@metallica ~]# rpm -q dnf dnf-1.1.8-1.fc23.noarch
"nobarrier,data=writeback" combined with battery backups for the win....