Taras: I cut this off at 1 Terabyte, assuming we don't care if we've got more space than that (at least as a proxy to measure disk fragmentation). Michal: this doesn't measure the case where a user has disabled smart-size cache (i.e. set a max cache size manually). But this is the common case, and piggybacks off us getting the size anyway, so no additional I/O at startup.

Comment on attachment 578804 [details] [diff] [review] v1 I think it would be nicer to report percentage of disk free since a fill rate corresponds better to fs usage.

Do we have a (portable) way to get disk space used on a device (or the total size of the device? Either of those plus nsILocalFile.diskAvailableFreeSpace is enough to get the %, but I don't see an API for either.

Comment on attachment 578804 [details] [diff] [review] v1 (In reply to Taras Glek (:taras) from comment #1) > I think it would be nicer to report percentage of disk free since a fill > rate corresponds better to fs usage. Why? We use absolute value to determine the cache size, so I think we should report that value. > + Telemetry::Accumulate(Telemetry::NETWORK_DISK_CACHE_FREE_SPACE_MB, > + bytesAvailable / (1024*1024)); > + > return SmartCacheSize((bytesAvailable / 1024) + currentSize); IMO we should log currentSize as well, or maybe only a sum of both.

(In reply to Michal Novotny (:michal) from comment #3) > Comment on attachment 578804 [details] [diff] [review] [diff] [details] [review] > v1 > > (In reply to Taras Glek (:taras) from comment #1) > > I think it would be nicer to report percentage of disk free since a fill > > rate corresponds better to fs usage. > > Why? We use absolute value to determine the cache size, so I think we should > report that value. That value would be useful for cache tuning. However a percentage is more useful for determining fragmentation. Sounds like we should do both.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258