On Wed, 2018-08-29 at 15:27 +0200, Markus Koschany wrote: > Am 29.08.2018 um 15:08 schrieb Uoti Urpala: > > If FPS stays sufficiently high that it's not a visible issue, you could > > try running the binary under strace for example and verify that there > > are lots of fsync calls while playing. (The calls probably aren't good > > for the SSD either, even if they don't prevent playing the game.) > > strace -e fsync -o /tmp/file neverball > > My point is that it isn't something most players would experience as a > serious performance penalty. The game hasn't changed in years, so either > it is not perceived as something really serious by many or there is a > recent regression in libphysfs. Then it should be fixed there.
I'm pretty sure it is a regression - years ago SSDs were not that common. And even if "most players" use it on machines with an SSD storing the save directory, the constant fsyncs likely increase SSD wear, so it's not harmless there either. > > > Not using libphysfs would be a workaround and not a fix. Hence I am > > > > I'm not sure why you're saying this. Given that upstream Neverball has > > also stopped defaulting to libphysfs use, it seems like a quite > > reasonable solution. > > Sure, not using your car when the tires are flat and instead going to > work by train is a reasonable solution, if you don't want to be late. > Most people will still want to fix the tires though because that's the > issue at hand. That comparison seems wrong. It assumes there are reasons you'd want to go back to the car (physfs) eventually. Given that upstream has changed the default, it's not an appropriate comparison here. > > AFAIK the version currently in Debian can be built with libphysfs > > disabled too. "Not actionable" seems like an exaggeration, even without > > packaging a new non-release version. > > > > I just ran a quick test, and building without libphysfs-dev worked with > > "git checkout neverball-1.6.0; make -j 6 ENABLE_FS=stdio". > > By not actionable I meant that upstream should do a proper release. This > is not something Debian can do. When they did that, we and all other However, changing the Neverball build configuration should be well within what is actionable by Debian. > distributions would package the new release. It is absolutely not clear > whether they consider all there other changes as feature complete. In > the worst case, we fix this bug but open a can of worms for other users. > Yes, usually it is not as bad for games but surely for other software in > the archive. There is also a good reason for using fsync. It protects > you against data loss. Cases where fsync() is the right tool are actually pretty rare. And this absolutely isn't one of them (particularly the Neverball save file case, but more generally physfs doing fsync() calls when the application hasn't explicitly requested them is not right either).