Open Bug 1671932 Opened 4 years ago Updated 8 days ago

Asynchronous non-blocking temporary storage initialization tolerating broken origins

Categories

(Core :: Storage: Quota Manager, task, P1)

task

Tracking

()

ASSIGNED

People

(Reporter: janv, Assigned: janv)

References

(Depends on 11 open bugs, Blocks 10 open bugs)

Details

Attachments

(1 obsolete file)

We are currently facing two major problems:

  1. Temporary storage initialization errors
  2. Slow temporary storage initialization in some cases

The temporary storage initialization must be currently successfully finished before a quota client can access files on disk (doesn't apply for the persistent repository).

If we could make the initialization asynchronous then we would mitigate the two major problems in a big way.

I'm still not 100% sure if it is feasible, but so far it looks good.

We are now fully working on this, it's our top priority.

Priority: P2 → P1
Depends on: 1680031
Depends on: 1689293

I think the description and summary should make one thing explicit that is currently implicit only: At the moment, storage initialization succeeds or fails atomically for all quota clients and origins. This bug intends to be change that so the success/failure is partial (per origin?). This is an important point, because this could be implemented (addressing problem number 1) independently from making initialization asynchronous (which addresses problem number 2). However, this bug specifically suggests to make both changes in one go.

That's true (partially), but it can't be easily implemented independently. I'll try to provide more details about that since I'm focusing on this more right now.

The main point here is that we currently allow only 100% accurate quota management. We want to change it so we will allow "inaccurate" usage tracking for the time the temporary storage is being initialized. So quota clients will be able to use storage even if the initialization is not finished yet. When the initialization finishes and we see that more data has been written than it would be allowed with synchronous initialization, we will evict some origins. After that we will have 100% accurate quota management/usage tracking again.
Once we do necessary changes for initializing origins asynchronously, then they naturally won't be able to break entire temporary storage initialization. The quota management will stay in "not 100% accurate" mode since we couldn't get exact usage for broken origins, The broken origins will stay uninitialized with some files on disk and they won't be included in overall usage calculations. The fact that we leave some extra files on disk which are not included in the usage calculations shouldn't be a big problem. We already had to make an exception for LSNG which tracks only logical size of the database. So the total physical size of all files doesn't have to match the usage we internally use for quota checks. We only allow to use 50% of free disk space anyway, so there should be a lot of space in reserve.

Summary: Asynchronous non-blocking temporary storage initialization → Asynchronous non-blocking temporary storage initialization tolerating broken origins
Depends on: 1690025

As part of this, the comment in QuotaManager::CollectOriginsForEviction should be addressed, see https://phabricator.services.mozilla.com/D101182#inline-580859.

Depends on: 1686031
Depends on: 1749504
See Also: → 1741865
Blocks: 1778472
Depends on: 1781204
Severity: S3 → S2
Priority: P1 → P2
Duplicate of this bug: 1741865

As I wrote on 1741865 if you need to profile or to test some firefox patched let me know as I have that issue only on my workstation since 2 years...

Blocks: 1804823
Blocks: 1792286
Blocks: 1817580
Depends on: 1839417
Depends on: 1840545
Depends on: 1840770
Blocks: 1848692
Duplicate of this bug: 1848692

One of the goals of bug 1671932 is to call EnsureTemporaryStorageIsInitialized
only from InitTemporaryStorageOp. Calling from other places including quota
clients will be disallowed by changing the method to a private method. The
private nature of the method should be emphasized by adding the Internal
suffix.

Changes done in this patch:

  • IsTemporaryStorageInitialized renamed to
    IsTemporaryStorageInitializedInternal
  • EnsureTemporaryStorageIsInitialized renamed to
    EnsureTemporaryStorageIsInitializedInternal

Depends on D186781

Depends on: 1855142
Depends on: 1808294

Comment on attachment 9353390 [details]
Bug 1671932 - Rename EnsureTemporaryStorageIsInitialized to EnsureTemporaryStorageIsInitializedInternal; r=#dom-storage

Revision D188332 was moved to bug 1808294. Setting attachment 9353390 [details] to obsolete.

Attachment #9353390 - Attachment is obsolete: true

Tracked by Reddit: https://old.reddit.com/r/firefox/comments/17u92cj/firefox_first_startup_high_disk_usage_io_wait/

This affects user experience and 2023 user experience is the key.

We are working really hard on this bug.

Depends on: 1866217
Depends on: 1866402
Priority: P2 → P1
Depends on: 1867997
Depends on: 1875995
Blocks: 1876935
Depends on: 1883353
Blocks: 1265504
Blocks: 1899015
Blocks: 1749007
Depends on: 1903186
No longer depends on: 1883353
Blocks: 1903530
No longer blocks: 1903530
Blocks: 1903530
Depends on: 1904562
Depends on: 1904674
No longer blocks: 1741865
No longer duplicate of this bug: 1741865
No longer blocks: 1848692
No longer duplicate of this bug: 1848692
See Also: 1741865
Depends on: 1904941
Depends on: 1913561
Depends on: 1913679
Depends on: 1914609
Depends on: 1919788
Depends on: 1920456
Depends on: 1920487
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: