= phenomenon = shared-mime-info's update-mime-database implementation suffered a serious performance regression from version 1.1 (in f19) to 1.2 (in f20) and newer.
= reason = shared-mime-info maintainers reacted to some reports of corrupted mime entries by implementing fdatasync for all writes. update-mime-database rpm scriptlets that once took ~0.2-0.7 seconds, now take ~30-45 seconds to complete.
I personally found f20 kickstart deployments that once took ~15 minutes for f19, were now taking ~45 minutes, and found this to be the primary cause. I tried to help out to find some compromise about restoring reasonable performance by default, but we've reached an impasse (see referenced bugs below).
We came close to a compromise solution, with upstream implementing a PKGSYSTEM_ENABLE_FSYNC environment variable. Our fundamental difference of opinion with whether it be enabled by default (and require opt-out) or disabled by default (and require opt-in).
My (biased) take on our positions: I insist that performance be restored by default asap while reasonable alternative solutions are sought out. I argue this data isn't that critical to warrant sync writes anyway, certainly not anything like an rpm database (where corruption could be fatal), and is easily (and quickly!) able to be regenerated as needed.
hadess insists that safety continue to be the default and workarounds elsewhere be implemented (e.g. rpm/yum set some PKGSYSTEM_ENABLE_FSYNC environment variable to opt-out).
= recommendation = I ask FESCo to review this case, and consider overruling Bastien Nocera's (CC'd) decision that update-mime-database continue to use fdatasync by default.
references: https://bugzilla.redhat.com/show_bug.cgi?id=1052173 https://bugs.freedesktop.org/show_bug.cgi?id=70366
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).
Replying to [ticket:1318 rdieter]:
I personally found f20 kickstart deployments that once took ~15 minutes for f19, were now taking ~45 minutes, and found this to be the primary cause.
2/3 of install time being spent in update-mime-database is absolutely crazy. Though, perhaps we should be making the rest of the system slower/more reliable rather than making update-mime-database faster/less reliable? (I’m actually somewhat serious.)
With ~700 individual files, and fdatasync() having to (serially!) block on a journal flush, a lot of the time spent waiting is clearly a waste. Though, that doesn’t mean I know what to recommend; can we get a FS expert to weigh in?
We came close to a compromise solution, with upstream implementing a PKGSYSTEM_ENABLE_FSYNC environment variable. OK, that would easily enough handle the anaconda case at least. As for post-install… I insist that performance be restored by default asap while reasonable alternative solutions are sought out. I argue this data isn't that critical to warrant sync writes anyway, certainly not anything like an rpm database (where corruption could be fatal), and is easily (and quickly!) able to be regenerated as needed. How can the user find out that they need to regenerate the mime database? hadess insists that safety continue to be the default and workarounds elsewhere be implemented (e.g. rpm/yum set some PKGSYSTEM_ENABLE_FSYNC environment variable to opt-out). That seems rather pointless; the update-mime-database tool would be perfectly safe, but all practical users of that tool would be run in the unsafe mode. This would end up shifting blame to rpm/yum, but not actually making the system update process safer. I ask FESCo to review this case, and consider overruling Bastien Nocera's (CC'd) decision that update-mime-database continue to use fdatasync by default.
We came close to a compromise solution, with upstream implementing a PKGSYSTEM_ENABLE_FSYNC environment variable. OK, that would easily enough handle the anaconda case at least. As for post-install…
I insist that performance be restored by default asap while reasonable alternative solutions are sought out. I argue this data isn't that critical to warrant sync writes anyway, certainly not anything like an rpm database (where corruption could be fatal), and is easily (and quickly!) able to be regenerated as needed. How can the user find out that they need to regenerate the mime database?
hadess insists that safety continue to be the default and workarounds elsewhere be implemented (e.g. rpm/yum set some PKGSYSTEM_ENABLE_FSYNC environment variable to opt-out). That seems rather pointless; the update-mime-database tool would be perfectly safe, but all practical users of that tool would be run in the unsafe mode. This would end up shifting blame to rpm/yum, but not actually making the system update process safer.
I ask FESCo to review this case, and consider overruling Bastien Nocera's (CC'd) decision that update-mime-database continue to use fdatasync by default.
I’d ''really'' like to get a FS expert involved. Who can we pull in?
Maybe drop update-mime-database from all specfiles, and add a yum/dnf plugin to only run it once at the end if the transaction involved files in %{_datadir}/mime/?
Fwiw, I've mentioned some way to achieve the ability to run once per transaction in the upstream bug report (similar to how gtk-update-icon-cache does it). It requires code/implementation of course, best done in shared-mime-info itself so everyone can benefit, not just fedora.
And some fruitful results: https://fedorahosted.org/fpc/ticket/440 for f21 and newer, which is a sufficient compromise that I'm willing to accept without reservation.
So, the only question I have remaining for FESCo, is to arbitrate the fedora 20 case: to accept the performance regression or not.
adding meeting keyword.
FESCo doesn’t require the fdatasync() behavior in F20 shared-mimo info to be modified
Login to comment on this ticket.