Do not store number of bytes written to the cache in preferences
Categories
(Core :: Networking: Cache, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox82 | --- | fixed |
People
(Reporter: michal, Assigned: michal)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
We use browser.cache.disk.amount_written as a persistent storage for number of bytes written to the cache. We should find a better storage because this is not a preference.
![]() |
||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
It looks like browser.cache.disk.amount_written
is the final Varcache pref. Once this is removed we can remove the Varcache machinery. Michal, is there any plan in place to fix this?
![]() |
||
Comment 2•5 years ago
|
||
Do you know if you will be able to spend time on this one, Michal? It would be really nice to remove the VarCache machinery... getting rid of it has been a multi-year project :)
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
This is the last VarCache pref and additionally, it shouldn't be a pref at all. I don't mind fixing this in light of everything but I'm not sure what the best fix will be since this can't just be a const. I could try to sync it up with a callback but what it really needs is some kind of persistent storage, not a pref.
Valentin, do you know if there is any mechanism necko can take advantage of so that we can get rid of this pref? Even if it stays as a pref it does things that prefs really shouldn't be doing and the use of VarCache needs to be removed regardless.
Great point Kris!
Right now the only persistent storage capabilities I'm aware of are:
- ssl/DataStorage this is written with specific uses in mind. I'd hate to add another one 🙂
- nsIKeyValueService this is probably the way to go.
- The HTTP cache; we could store the value as metadata, but entries are not persistent this is not a great option.
So, I suppose a nsIKeyValueService for network properties would be the solution here.
Assignee | ||
Comment 5•5 years ago
|
||
In the end, I think it should be stored inside the cache. If we lose the cache for whatever reason, it's OK that we lose this number too. If we store it directly inside the index (and not e.g. in a cache entry), we might lose it also when we lose only the index and not the whole cache, but given that it probably doesn't happen often and this number is used only for telemetry purposes, it's OK too. I'll try to create the patch...
Assignee | ||
Comment 6•5 years ago
|
||
Comment 8•5 years ago
|
||
bugherder |
Description
•