Cached quota information is not used when last access time information mismatches
Categories
(Core :: Storage: Quota Manager, defect, P1)
Tracking
()
People
(Reporter: janv, Assigned: janv)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
diannaS
:
approval-mozilla-release+
|
Details | Review |
102.48 KB,
image/jpeg
|
Details |
This seems to be causing persistent startup slowdown in FF 120.
Assignee | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Comment 3•1 year ago
|
||
bugherder |
Comment 4•1 year ago
|
||
Comment on attachment 9365912 [details]
Bug 1867095 - Make it possible to use cached quota information even when last access time information mismatches; r=#dom-storage
Taking in 121 beta 5 as we intend to take it in our 120 dot release.
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Comment on attachment 9365912 [details]
Bug 1867095 - Make it possible to use cached quota information even when last access time information mismatches; r=#dom-storage
Unsetting the beta approval to allow Jan to provide more information and especially STRs.
Assignee | ||
Comment 6•1 year ago
|
||
The fix can be tested by going to about:telemetry after startup and checking QM_QUOTA_INFO_LOAD_TIME_V0. The value went down from ~2000 to ~100 (msecs) for me after the fix. I have ~30K files in my profile.
Note that the value can be one time higher after updating FF (when build id changes).
Assignee | ||
Comment 7•1 year ago
•
|
||
Comment on attachment 9365912 [details]
Bug 1867095 - Make it possible to use cached quota information even when last access time information mismatches; r=#dom-storage
Beta/Release Uplift Approval Request
- User impact if declined: Users would still observe persistent startup delay caused by full storage initialization.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce:
- Run a build without the fix with some existing profile which contains many files (at least several thousands) in <profile>/storage (a profile which is known to cause persistent startup delay)
- Wait several seconds for storage initialization to finish
- Go to about:telemetry and check QM_QUOTA_INFO_LOAD_TIME_V0. The value should be greater than 1000 msecs
- Quit the app
- Run a build with the fix included with the same profile
- Wait several seconds for storage initialization to finish
- Quit the app
- Run the same build with the fix included with the same profile
- Wait a second
- Go to about:telemetry and check QM_QUOTA_INFO_LOAD_TIME_V0. The value should be an order of magnitude less than the previous value
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Very simple and safe patch
- String changes made/needed: None
- Is Android affected?: Yes
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 9•1 year ago
|
||
Comment 10•1 year ago
|
||
Managed to reproduce the issue on Firefox 120.0. "QM_QUOTA_INFO_LOAD_TIME_V0" value was above 2500.
The issue is fixed on Firefox 122.0a1 (2023-11-29) and on Firefox 121.0b5 on macOS 11.6. After the second restart the value of "QM_QUOTA_INFO_LOAD_TIME_V0" dropped to 20.
Comment 11•1 year ago
|
||
Comment on attachment 9365912 [details]
Bug 1867095 - Make it possible to use cached quota information even when last access time information mismatches; r=#dom-storage
Approved for 120.0.1 dot release
Updated•1 year ago
|
Comment 12•1 year ago
|
||
uplift |
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Verified as fixed on Firefox 120.0.1 on macOS 11.6.
Is this a regression by bug 1858067? (Posting here as bug 1867035 is duped.)
Assignee | ||
Comment 16•1 year ago
|
||
Yeah, it seems that's it. There was a patch which cleaned up the interaction of operations for saving origin access time and shutdown, https://phabricator.services.mozilla.com/D187877. Before the patch, the operation could sometimes fail due to ongoing shutdown (likely causing a failure during loading of quota information after next startup, causing a startup delay). The patch fixed that, so the access time was then reliably stored for all origins even if shutdown was ongoing. However, the additional IO during shutdown caused that the improvements for reducing shutdown time done in bug 1733107 were negated, so we decided to avoid saving of origin access time if shutdown already started. Unfortunately the patch for bug 1858067 done that only for metadata files and not for cached information. Ideally, we would have a test for catching regressions like this. Automatic watching of telemetry might help, but it usually takes several days to see noticeable changes in collected data.
Description
•