Browse Source
s3: optimize DELETE by skipping lock check for buckets without Object Lock
s3: optimize DELETE by skipping lock check for buckets without Object Lock
This optimization avoids an expensive filer gRPC call for every DELETE operation on buckets that don't have Object Lock enabled. Before this change, enforceObjectLockProtections() would always call getObjectEntry() to fetch object metadata to check for retention/legal hold, even for buckets that never had Object Lock configured. Changes: 1. Add early return in enforceObjectLockProtections() if bucket has no Object Lock config or bucket doesn't exist 2. Add isObjectLockEnabled() helper function to check if a bucket has Object Lock configured 3. Fix validateObjectLockHeaders() to check ObjectLockConfig instead of just versioningEnabled - this ensures object-lock headers are properly rejected on buckets without Object Lock enabled, which aligns with AWS S3 semantics 4. Make bucket creation with Object Lock atomic - set Object Lock config in the same CreateEntry call as bucket creation, preventing race conditions where bucket exists without Object Lock enabled 5. Properly handle Object Lock setup failures during bucket creation - if StoreObjectLockConfigurationInExtended fails, roll back the bucket creation and return an error instead of leaving a bucket without the requested Object Lock configuration This significantly improves DELETE latency for non-Object-Lock buckets, which is the common case (lockCheck time reduced from 1-10ms to ~1µs).pull/7642/head
7 changed files with 113 additions and 42 deletions
-
2test/s3/retention/s3_object_lock_headers_test.go
-
13test/s3/retention/s3_retention_test.go
-
13weed/s3api/s3api_bucket_config.go
-
78weed/s3api/s3api_bucket_handlers.go
-
1weed/s3api/s3api_object_handlers_delete.go
-
30weed/s3api/s3api_object_handlers_put.go
-
18weed/s3api/s3api_object_retention.go
Write
Preview
Loading…
Cancel
Save
Reference in new issue