Trading off safety and performance in the kernel

Posted May 13, 2015 23:37 UTC (Wed) by imunsie (guest, #68550)
In reply to: Trading off safety and performance in the kernel by zblaxell
Parent article: Trading off safety and performance in the kernel

I think you probably missed my (admittedly subtle) point - while suspend/result may work reliably for you, it still is a complete mess for other people, so removing the sync seems like a terrible idea (a tunable would be ok, so long as it still does a sync by default).

As a side note, suspend/resume was actually working very reliably on my laptop until about three or four months ago when *something* (Kernel? Debian? systemd?) updated and completely broke it after the laptop had been in the dock (I really CBF tracking down yet another regression because I have better things to do with my time). But that's beside the point - if it doesn't work for me, it stands to reason that it doesn't work for a lot of other people, so it's not reliable.

Trading off safety and performance in the kernel

Posted May 14, 2015 0:07 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

The best outcome is going to be a tunable. Good or bad, the changing the default sync behavior will take years to be fully accepted, and even after all the major userspaces catch up, there will probably always be a few people who are stuck with buggy legacy userspace and firmware at the same time.

A tunable lets individual users choose when they make the transition. Look how long it took for atime to stop being the default to get an idea how long such a change can take.

There are always kernel regressions and crashes that lose some uncommitted data. We don't run filesystems in sync mode all the time because the performance (and wear and tear on disks, rotating or otherwise) is a price too high for the negligible benefit of less data lost on a crash. At some point that sync on suspend *must* go away.