Closed Bug 1186877 Opened 9 years ago Closed 6 years ago

Fsync when writing to session-state.json

Categories

(Toolkit :: Telemetry, defect, P4)

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox42 --- affected

People

(Reporter: Dexter, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [unifiedTelemetry] [measurement:client])

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.
Blocks: 1120356
Whiteboard: [unifiedTelemetry]
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`?
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.
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?
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?
Blocks: 1122482
No longer blocks: 1120356
Blocks: 1201022
No longer blocks: 1122482
Priority: -- → P4
Whiteboard: [unifiedTelemetry] → [unifiedTelemetry] [measurement:client]
I venture that since we've been living with this behaviour for four years we're probably okay with it :)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.