Alessio Placitelli [:Dexter] Reporter
	Description • 9 years ago

We should decide if it's worth fsync session-state.json when using writeAtomic for extra safety (and small risk of jank).

If we decide to fsync, we should check with with bcolloran to set up an experiment to measure the benefit of the fsync and also measure the fsync cost with a Telemetry histogram.

	David Teller [:Yoric] - still alive but not very active
	Comment 1 • 9 years ago

So far, we have preferred to avoid using `fsync` in our code, except for extra-sensitive data. In the worst case scenario, how much data could we lose by not using `fsync`?

	Alessio Placitelli [:Dexter] Reporter
	Comment 2 • 9 years ago

In the worst case scenario, we could loose information about the previous subsession/session ids, which are helpful to create a sequence of sessions for Telemetry on the servers.

We would also loose the subsession counter for the current profile.

	David Teller [:Yoric] - still alive but not very active
	Comment 3 • 9 years ago

Would it be possible to attain the same level of safety by keeping a backup somewhere? For instance by not overwriting session-state.json, but moving it to session-state.old, and using session-state.old to reconstruct any data in case session-state.json is corrupted?

	Georg Fritzsche [:gfritzsche]
	Comment 4 • 9 years ago

That wouldn't improve things, we would still lose the chaining to the latest data.

I wonder if we can't find out if that is actually a significant problem?

	Chris H-C :chutten
	Comment 5 • 6 years ago

I venture that since we've been living with this behaviour for four years we're probably okay with it :)