Make insufficient storage errors visible without attempting too frequent uploads

[ckamm]

This is a follow up to #5346 and owncloud/enterprise#1831.

Before 2.3, 507 Insufficent Storage errors used to be blacklisted. That had the positive effect of making the client not reattempt the upload very frequently. But it also hid the error and sometimes users weren't even aware that there was a storage problem.

For 2.3 we removed the blacklisting. That made the error visible, but lead to too-frequent uploads.

The behavior of the client in situations with insufficient storage space on the server needs to be adjusted. We want users to become aware of the problem while not attempting too many uploads that have a high likelihood of failure.

[ckamm]

Okay, so what do we want to happen if the server has insufficient storage?

The obvious path would be to trust the quota the server reports and prohibit uploads that would exceed the quota and make the whole sync fail with a "Insufficent storage" normal error if that happens.

That means that the client would need to have a model of "free server disk space" that's kept up to date during the sync process. It also means we need to update quota regularly from the server even if the settings dialog is not shown (or do it before the sync?).

[SamuAlfageme]

@ckamm +1 to being reactive to the quota, that would solve collateral problems like: #5346 (comment) (changes in user's quota)

[ckamm]

@SamuAlfageme Actually, using quota changes to trigger syncs is not part of this commit yet.

To do that, we'd need to check quota regularly, even if the settings dialog is not visible. We'd also need to track that there are files that couldn't be synced due to quota limitations. It goes beyond what I wanted to accomplish here.

[ckamm]

Unfinished pull request: #5552

Current status: We can have different quotas per folder and currenty don't track them. Fully addressing this needs significantly more work.

[GrendelOnCampus]

Hello, I understand the problem. You can have your own folder and a share from another user. But if one account is full, you can't upload to that folder. The client does only see the sum and thinks, that he can upload. So far, so good.

Maybe we can realize a solution in 2 steps?

1. when encountering "Insufficient Storage" error for several times, slowing down the attempts for upload. First a few seconds upto several minutes. Each time let the client put an error message via popup. So we don't fill the logs with more than 80000 tries from just 1 user, as I've seen today. This delay-interval can be decreased again, when the server stops sending error messages about storage.
2. making the server smart, that it reports the quota for several upload paths so the client can stop uploading the folders, which are full. Restart will only begin with this folder, when the server reports free space again for this particular upload path.

BTW... step 1 can stay active too, even when #2 is realized...

Just my proposal to this issue.

[ckamm]

@DeepDiver1975 @michaelstingl and me spoke about this in detail. Summary:

• The main issue is seeing 507 errors in the server log.
• They appear because the client treats a PUT (or chunk-done MOVE) as a cheap way to say "I want to upload if there's enough space". This is correct behavior. The client could do a PROPFIND before each PUT to make running into the error less likely, but the extra request per upload would be significant overhead.
• There's currently no API to retrieve all "quota-roots". The client has to assume that each folder could have a different quota.
• When a 507 is seen the problem will not usually resolve itself: some user action (deleting other files, adding storage) is necessary. But we do want the client to sync everything automatically once this intervention has happened. That means the client must retry, poll quota, or something like that.
• More generally, this is not just about 507s. It's about any error that can come up in regular operation and isn't an error the server admin needs to do something about.

My main suggestion:

• Don't show 507 errors in owncloud.log: They do not indicate an actionable server error.

An alternate path that's more costly but would also fix the issue:

• In the client, once you encounter a 507, switch into a PROPFIND-before-upload state.

In addition I'm in the process of improving error display and messaging for these kind of errors in the client. I might also add logic to not retry larger files in the same directory once a 507 has been seen.

[ckamm]

The "make 507 errros visible" part is addressed by #5890. It also gives users the ability to say "retry now" when they have solved the problem.

[ckamm]

The PR #5892 skips uploads that would clearly lead to more 507s. It doesn't change the basic approach.

[ckamm]

I think the best approach to avoiding excessive 507 entries in the server error log is to not put them there. See #5537 (comment) . I'd start on a client-side avoidance strategy only if it's strictly necessary.

[ckamm]

I assume this is good now.