https://bugs.kde.org/show_bug.cgi?id=187172
--- Comment #48 from Martin Steigerwald <mar...@lichtvoll.de> --- (In reply to Kai Krakow from comment #47) > (In reply to Martin Steigerwald from comment #46) […] > So if this discussion is about whether we should remove `KDE_EXTRA_FSYNC`, > I'd rather not have it force-enabled, especially because KDE seems to be > very busy with its config files and reads and writes them a lot (similar to > the cache directory). IMHO, the variable could be changed to require > `KDE_DISABLE_EXTRA_FSYNC=this_is_dangerous_and_I_know_what_I_am_doing`. This > may make it more obvious to people who blindly follow some internet guides > to "make things faster" that they may be doing something harmful. Well for special cases there could be an option to switch off the syncing. But the default nowadays should really be on the safe side. From what I read from you, Kai, we can agree on this much, can we? I am okay with renaming the variable to the non default case like KDE_DISABLE_EXTRA_FSYNC and have it off by default. Not sure whether any "iknowwhatiamdoing" is needed. Its not exposed in a configuration GUI to begin with. Is it really that much of an issue with BTRFS? Especially since I switched to laptop with NVME SSD I am not aware of any issues here. That written, I have no direct comparison with home directory being on XFS, I bet it would feel faster, but I am not actually waiting on filesystem writes to begin with. At least as long as Baloo only indexes filenames and Akonadi indexer is disabled (waiting for "make indexing great again"). On another system I do have Baloo completely enabled, as there are way less files. Anyway, this is getting of topic as well I am looking forward to try with BCacheFS in the future which with it frontend / backend architecture may solve any performance issues with syncing in a filesystem of the new generation (with snapshots and so on). -- You are receiving this mail because: You are watching all bug changes.
