Unable to reproduce this issue on reported version 58.0.3029.96, on latest stable 63.0.3239.132 with below steps using Ubuntu 14.04 and Ubuntu 17.10

1. Freshly installed chrome and opened crbug.com
2. In devtools console paste above code and observed "we are using 0 of 7631580910 bytes"

This might be specific to Ubuntu 16.04. As ET team doesn't have Ubuntu 16.04 could someone from Inhouse team please take a look.

Thanks!

Deleted: M63 behaviour.png 243 KB

	M63 behaviour.png 243 KB View Download

Deleted: 58.0.3029.96 behaviour.png 672 KB

	58.0.3029.96 behaviour.png 672 KB View Download

I get another computer running Ubuntu 16.04 and I did the test on it. I don't reproduce the bug with.

So it seems to be linked to something else than the distrib version only.

For information the computer that reproduce the bug is a MacBook Pro 2015 running Ubuntu 16.04 on dual boot

Can you visit chrome://quota-internals/ and report what the "Free disk space for the profile directory"  is reporting?

I try both on version 57 and 63 and it gives me the same result : 

Free disk space for the profile directory.	2.24 GB (2,249,777,152 B)

errors-on-evicting-origin	0
errors-on-getting-usage-and-quota	0
evicted-origins	0
eviction-rounds	1
skipped-eviction-rounds	1

Thanks for checking. For 57 and earlier the pool size calculation was 1/3 of free space. An origin gets up to 1/5 of the pool. 2.2GB free * 1/3 * 1/5 = about 150MB which is what you were seeing.

Circa 58 we changed our temporary pool size calculation from being something like 1/3 of *free space* to 1/3 of *volume size*, but ensuring 10% of the drive remains free.

What is your overall disk size? If it's greater than say 200GB then we probably come up with "must keep at least 2GB free" and so Chrome won't be the bad app that uses your last 2 GB of space.

We should reflect all of these numbers in quota-internals for easier diagnostics. I'll file a bug on that.

(We have another threshold at 1% where we actively discard even previously stored data, but I don't think that's relevant here.)

Filed issue 803977

Your analyze is absolutely correct. I though about it but I was misleading by the fact that I checked inside a windows VM on the same computer having the same free space amount but I missed the fact that the windows partition was smaller so the 10% of the drive is not the same and it granted me some space.

I think that it would be great that this numbers were displayed in the storage tab of devtools, I don't know if it is me but I spend my life in devtools but never though to go in quota-internals. maybe just a warning in the dev tool tab "you're running out free space" with a link open quota-internal in a new tab.

Thanks for your time anyway !

Yeah, devtools would be great too. Another bug coming up...

Filed issue 804002

Keeping this open since the change was intentional but it's definitely caused regressions like this in some cases. We could improve the heuristics further, and this is a valuable case to keep in mind - mostly-full disks. 

As this issue related to storage>quota seems it is out of scope from TE end,hence adding 'TE-NeedsTriageHelp' for further information and removed 'Needs-bisect' and TE-NeedsTriageFromHYD labels for now.

Thanks..!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9508bf4e08990e7024140cf96436f21239cb17c3

commit 9508bf4e08990e7024140cf96436f21239cb17c3
Author: Joshua Bell <jsbell@chromium.org>
Date: Fri Feb 23 18:05:20 2018

Quota: Reduce "should/must remain available" thresholds

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.

The threshold was set at 10%, which is too conservative; offline
storage would basically stop working when a disk was 90% full, which
is a common case - e.g. on a 200GB disk, writes start to fail with
20GB free! This change adjusts the threshold to 1%; for example, on a
32GB device this ensures Chrome does not push usage past 320MB
remaining free.

Similarly, Chrome has a "must remain available" threshold at which
point data starts being evicted - keeping the device functional, but
potentially losing user data. This was set at 1%, but is similarly
adjusted down to 0.25%. For a 32GB device this ensures Chrome will
drop data only when less than 80MB are free.

Bug:  802027 
Change-Id: I09ec3531ef34637413a1d239b546dc200d3d648a
Reviewed-on: https://chromium-review.googlesource.com/933365
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538818}
[modify] https://crrev.com/9508bf4e08990e7024140cf96436f21239cb17c3/storage/browser/quota/quota_settings.cc
[modify] https://crrev.com/9508bf4e08990e7024140cf96436f21239cb17c3/storage/browser/quota/quota_settings.h

Fingers crossed, but the new numbers should resolve this side of the issue. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e5b5704d062321a0c6d000224573661029b4b19

commit 1e5b5704d062321a0c6d000224573661029b4b19
Author: Joshua Bell <jsbell@chromium.org>
Date: Wed Feb 28 06:36:29 2018

Quota: Refine "should/must remain available" thresholds

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.

The thresholds were set as a percentage of the disk size, but after
further consultation these are changed to absolute values (2GB for
"should" and 1GB for "must") to make the behavior more predictable and
to ensure more space on low end devices to accomodate e.g. app
updates.

Bug:  802027 , 817128 
Change-Id: I3a081d4e17d0e5ad74fb4e877f919f0cc1bec5b2
Reviewed-on: https://chromium-review.googlesource.com/940185
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539735}
[modify] https://crrev.com/1e5b5704d062321a0c6d000224573661029b4b19/storage/browser/quota/quota_settings.cc

As per comment#11 this is out of scope of verifying from TE end as this is related to Storage>Quota. 

@jsbell: Please help in verifying the fix.

Thanks!