New Storage Quota Threshold is Overly Strict
Reported by
developm...@crimsontide.co.uk,
May 2 2018
|
|||||||||
Issue descriptionSteps to reproduce the problem: A device with very low disk space as standard (e.g. Samsung J3 2016 with 8GB) will have around 4GB free space after default apps and Android are installed, it does not require much to be installed or done on the device before it dips below 1GB - through entirely routine usage. At this point the device stops being able to write to IndexedDB as the Storage quota is automatically exceeded. What is the expected behavior? Storage space should be reserved from use by Chrome storage but this should be a weighted amount depending on the device disk space, acknowledging that devices with less disk space can more readily hit the 1GB limit through normal, non-problematic usage quite separate from any use by Chromium. A reasonably high amount should still be preserved, less than 1GB but more than 1%. What went wrong? This is a change to the restriction that was added in commit 1e5b5704d062321a0c6d000224573661029b4b19 With the devices I mention above, and frankly a lot of larger disk spaced, more premium devices as well, 1GB is a very significant proportion of storage. I can certainly understand the logic behind preserving a significant amount of space to allow normal functioning of the OS as well as being able to download large updates and that the previous 1% was not fit for purpose but surely a flat 1GB is too far to the other extreme and lacks the required flexibility to account for all the multitudinous devices in the Android family. In our case, the update to M66 has caused our hybrid app to cease working on a significant subset of our customer's devices, overnight, as a number are using cheap devices which were hovering around 800-950mb used. This is despite our app only using about 5-35mb of IndexedDB storage. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.126 Channel: stable OS Version: >=5 Flash Version: Essentially this seems like a sledgehammer to crack a nut, especially considering that under 2GB trips the "should remain available" limit and data is liable to be deleted. I hope that this change can be revised, at least partially so a better balance can be struck. Purely web based storage solutions are very limited if lower spec devices are restricted in this way, especially in Web Workers where IndexedDB is the only storage API available. PWAs could also be especially badly hit with this change as they don't have access to other native options that our hybrid app does.
,
May 2 2018
Issue 838912 has been merged into this issue.
,
May 2 2018
,
May 2 2018
,
May 2 2018
,
May 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73b18e372a83137f1198a350973225c4c145ceb6 commit 73b18e372a83137f1198a350973225c4c145ceb6 Author: Joshua Bell <jsbell@chromium.org> Date: Wed May 02 23:06:29 2018 Quota: Revert "should/must remain available" changes on low-end devices Chrome has a "should remain available" disk space threshold; when less than this amount is free, the effective quota for each origin drops to 0 so new writes will fail. This is present to avoid Chrome being responsible for filling the disk which generally makes devices unhappy. Similarly, Chrome has a "must remain available" threshold at which point data starts being evicted - keeping the device functional, but potentially losing user data. In r538818 and r539735 in M66 the thresholds were changed from 10% and 1% to a fixed 2GB and 1GB respectively, to reduce the amount reserved on high-end devices - 10% of a 1TB machine is a lot! But this did not account for the impact on low end devices, e.g. 16GB or even 8GB, where the reserve substantially increased, reducing the usability of Chrome. Change the algorithm to use min(fixed, ratio) where fixed values remain 2GB/1GB and the ratios revert back to 10%/1%, restoring the previous availability on storage on low end devices. Bug: 838816 Change-Id: I7d60ae614d6be7a99cfaaa29f2aac9ce25ce861e Reviewed-on: https://chromium-review.googlesource.com/1039879 Commit-Queue: Daniel Murphy <dmurph@chromium.org> Reviewed-by: Daniel Murphy <dmurph@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#555600} [modify] https://crrev.com/73b18e372a83137f1198a350973225c4c145ceb6/storage/browser/quota/quota_settings.cc
,
May 3 2018
This should be fixed in Canary. I'll let it bake for a few days then request merge to M67.
,
May 3 2018
Also: thank you to the issue reporters for extremely detailed analysis on the cause and impact.
,
May 4 2018
Thank you for being so responsive to the issue - it really is encouraging as a web developer to see such a proactive response from Chromium!
,
May 8 2018
,
May 8 2018
This bug requires manual review: Reverts referenced in bugdroid comments after merge request. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 8 2018
How safe is this CL to be merged into M67 branch at this point? Has it been verified in canary?
,
May 9 2018
Can any of the reporters confirm in a Canary build on low-end Android that the behavior has been correctly reverted?
,
May 10 2018
Ping!
,
May 11 2018
We are also experiencing this issue on Chrome 66. I tested on Canary 68.0.3427.0 released 5/11/2018 and the issue no longer occurs. Device is SM-G360M with ~650MB of free space.
,
May 11 2018
Sorry for the delay in response, I can also confirm that this is working in Canary (68.0.3427.0) on an SM-J320FN with 572mb free. I am given ~327mb of quota in Canary, whereas with Chrome (66.0.3359.158) I am given no more than I am already using.
,
May 11 2018
Thanks, reporters! cmasso@: * verified in canary, per above. * change is safe; scoped to quota, basically a revert of a heuristics change for low-storage devices
,
May 11 2018
,
May 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2856e8c2a3616bd57b33670ff5215e472f81a2c4 commit 2856e8c2a3616bd57b33670ff5215e472f81a2c4 Author: Joshua Bell <jsbell@chromium.org> Date: Fri May 11 17:50:19 2018 Quota: Revert "should/must remain available" changes on low-end devices Chrome has a "should remain available" disk space threshold; when less than this amount is free, the effective quota for each origin drops to 0 so new writes will fail. This is present to avoid Chrome being responsible for filling the disk which generally makes devices unhappy. Similarly, Chrome has a "must remain available" threshold at which point data starts being evicted - keeping the device functional, but potentially losing user data. In r538818 and r539735 in M66 the thresholds were changed from 10% and 1% to a fixed 2GB and 1GB respectively, to reduce the amount reserved on high-end devices - 10% of a 1TB machine is a lot! But this did not account for the impact on low end devices, e.g. 16GB or even 8GB, where the reserve substantially increased, reducing the usability of Chrome. Change the algorithm to use min(fixed, ratio) where fixed values remain 2GB/1GB and the ratios revert back to 10%/1%, restoring the previous availability on storage on low end devices. Bug: 838816 Change-Id: I7d60ae614d6be7a99cfaaa29f2aac9ce25ce861e Reviewed-on: https://chromium-review.googlesource.com/1039879 Commit-Queue: Daniel Murphy <dmurph@chromium.org> Reviewed-by: Daniel Murphy <dmurph@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#555600}(cherry picked from commit 73b18e372a83137f1198a350973225c4c145ceb6) Reviewed-on: https://chromium-review.googlesource.com/1055708 Reviewed-by: Joshua Bell <jsbell@chromium.org> Cr-Commit-Position: refs/branch-heads/3396@{#568} Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428} [modify] https://crrev.com/2856e8c2a3616bd57b33670ff5215e472f81a2c4/storage/browser/quota/quota_settings.cc
,
May 14 2018
Issue 842739 has been merged into this issue.
,
May 22 2018
,
May 22 2018
Yeah men, this seems to be something yo worry about. I do support you. My PWA APP is experimenting this kind of behaviour.. If some of hoy know to fix this it would be reeally appreciated. Pls DO NOT MERGE THE ISSUES!!
,
May 24 2018
Issue 845958 has been merged into this issue.
,
Jun 20 2018
@jsbell - you might want to update the answer of David Grogan at StackOverflow with the current intricacies of the world - https://stackoverflow.com/a/11077695/1276639 |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by rodfreit...@gmail.com
, May 2 2018