| Summary: | Excessive fdatasync in KConfig::sync | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-ktexteditor | Reporter: | pbs3141 |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | christoph, kdelibs-bugs, mpyne, rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/ktexteditor/-/commit/44142fded87e3d571488d509f804741589d67beb | Version Fixed In: | |
| Sentry Crash Report: | |||
I can confirm KConfig::sync()s are happening that appear to be needless, which results in lock files being generated. This happens about 2-3 times for me on startup which isn't "excessive" IMO but is definitely not optimal. The fdatasync() are almost certainly intentional as part of QLockFile though, but I think it would only be necessary as part of the 'stale lock' detection (otherwise the contents of the lock file do not matter, only its presence in the directory is important for locking). Removing the fdatasync and relying on the FS's own data commit timing would be an upstream bug. That still leaves the question of why the KConfig object is promptly becoming dirty upon startup (the KConfig::sync method already avoids touching the disk if it doesn't think a writeback is necessary), or whether a QLockFile is the best anti-contention tool (maybe there's some kind of in-memory processed-shared primitive that would work... though that way is fraught with problems of its own). I think the sync is not the fault of the kconfig but a fault of our implementation in KTextEditor. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/574 Git commit 44142fded87e3d571488d509f804741589d67beb by Christoph Cullmann. Committed on 04/07/2023 at 07:19. Pushed by cullmann into branch 'master'. avoid config syncs and updates on initial construction M +36 -4 src/utils/kateconfig.cpp M +6 -10 src/utils/kateconfig.h https://invent.kde.org/frameworks/ktexteditor/-/commit/44142fded87e3d571488d509f804741589d67beb |
Overview: When any KDE 5 app starts, there is a short delay and an audible burst of disk thrashing. This is a regression from KDE 4 where applications started up instantly and with no disk thrashing. Taking kwrite as an example, for each new instance started there is a delay of ~ 0.5s and a disk access. For each instance closed, there is also a shorter disk access. This happens even though my fstab contains "commit=300", indicating I wish to keep the last 5 minutes of data volatile in return for better performance. Observed behaviour: From strace, it turns out kwrite is calling fdatasync on the following files, for every instance started: ~/.config/kwriterc.lock ~/.config/kwriterc.XM{#1} ~/.config/session/kwrite_{#2}.lock ~/.config/session/kwrite_{#2}.nS{#1} From gdb, the chain of events is: KConfig::sync -> QLockFile::tryLock / QSaveFile::commit -> fdatasync Using a tmpfs home directory makes the disk thrashing go away, but not the startup delay. Conclusion: KConfig performs aggressive syncing of config files, causing all KDE 5 apps to have excessive HDD usage. (The startup delay is an unrelated problem that is worth investigating, but I haven't found what it is yet.) Calling fdatasync all the time overrides whatever data consistency guarantees the user may actually want. In any case, forcing a disk sync on startup and exit of every single application is certainly excessive. This is not to mention that starting a program doesn't even produce any new data that is essential to sync immediately. I am not sure whether this behaviour is intentional, or the devs just haven't noticed it due to having quieter disks - hence why this bug report exists.