Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe MinIO behavior with regards to multi-part uploads #1216

Open
ramondeklein opened this issue May 14, 2024 · 4 comments
Open

Describe MinIO behavior with regards to multi-part uploads #1216

ramondeklein opened this issue May 14, 2024 · 4 comments
Labels
triage Needs triage and scheduling

Comments

@ramondeklein
Copy link
Contributor

MinIO behavior with regards to multi-part uploads deviates from AWS S3 in the following ways:

  • MinIO doesn't allow listing all current multi-part uploads in a bucket.
  • MinIO automatically purges non-aborted multi-part uploads after 24 hours.

Issues minio/minio#5613, minio/minio#11686 and minio/minio#13246 proof that ListMultipartUploads can only be used to list multi-part uploads if an exact object-name is specified as a prefix.

Issue minio/minio#16120 confirms that AbortIncompleteMultipartUpload is not supported when using PutBucketLifecycle. It looks like we're scanning every 6 hours and purge non-aborted multi-part uploads after 24 hours (see stale_uploads_expiry and stale_uploads_cleanup_interval in the docs). This behavior affects all APIs that deal with aborting incomplete multipart uploads lifecycle rules.

I think we should mark the APIs in the S3 API compatibility document that have restrictions and/or deviate from the standard AWS S3 APIs and provide a proper explanation why we deviate.

@ramondeklein ramondeklein added the triage Needs triage and scheduling label May 14, 2024
@feorlen
Copy link
Collaborator

feorlen commented May 14, 2024

We can expand the compatibility page to add this type of information. In the process, it would be nice to move the small section on unsupported APIs from the thresholds and limits page to the compatibility page.

@djwfyi
Copy link
Collaborator

djwfyi commented May 29, 2024

We can expand the compatibility page to add this type of information. In the process, it would be nice to move the small section on unsupported APIs from the thresholds and limits page to the compatibility page.

All of the APIs referenced on the thresholds and limits page are already listed in the unsupported API bucket endpoint list.
Maybe a link between the two pages? Or just delete the section on the limits page?

@ramondeklein
Copy link
Contributor Author

@djwfyi The ListMultipartUploads limitations are not described on that page.

@djwfyi
Copy link
Collaborator

djwfyi commented May 29, 2024

@djwfyi The ListMultipartUploads limitations are not described on that page.

@ramondeklein Right. I was commenting on @feorlen's suggestion of expanding the scope of the request.

I do fear that this is a rabbit hole we don't have enough bandwidth or insight to address at the moment, but I agree that it is a good request. Just if we do it for multipart, we should expand all of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Needs triage and scheduling
Projects
None yet
Development

No branches or pull requests

3 participants