[ 
https://issues.apache.org/jira/browse/HDDS-16771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Siyao Meng updated HDDS-16771:
------------------------------
    Attachment: CR-5-mark-hsync-open-key-overwritten-by-mpu-complete.patch

> CompleteMultipartUpload over an hsync'ed key does not flag the hsync writer's 
> open entry
> ----------------------------------------------------------------------------------------
>
>                 Key: HDDS-16771
>                 URL: https://issues.apache.org/jira/browse/HDDS-16771
>             Project: Apache Ozone
>          Issue Type: Bug
>            Reporter: Siyao Meng
>            Priority: Major
>         Attachments: 
> CR-5-mark-hsync-open-key-overwritten-by-mpu-complete.patch, 
> TestBugCR5HsyncMpuComplete.java
>
>
> h3. Mechanism
> {{S3MultipartUploadCompleteRequest.validateAndUpdateCache}} replaces an 
> existing file table entry without checking {{HSYNC_CLIENT_ID}} on it and 
> without adding {{OVERWRITTEN_HSYNC_KEY}} to the hsync writer's open entry. 
> {{OMKeyCommitRequestWithFSO}} ({{:198-213}}) and {{OMKeyCommitRequest}} do 
> both for a normal overwrite. No code under {{request/s3/multipart/}} reads or 
> writes hsync metadata, so every bucket layout that allows hsync is affected; 
> it was shown on FSO.
> h3. Trigger
> {{ozone.fs.hsync.enabled}} and {{ozone.hbase.enhancements.allowed}} are true 
> (both default false), FSO bucket.
> # Writer A creates a file through {{ofs}} / {{o3fs}} and hsyncs it.
> # Another client completes a multipart upload on the same key.
> # Writer A hsyncs after crossing a block boundary, or closes.
> h3. Impact
> Writer A's stale hsync or close is accepted and silently replaces the 
> completed multipart object, which is moved to the deleted table. A normal 
> overwrite in the same position rejects writer A with {{KEY_NOT_FOUND}}. At 
> complete time writer A's hsync'ed version goes to the deleted table with its 
> blocks, and A's accepted commit then writes a key table entry that references 
> those same blocks, so the file that comes back points at blocks already 
> queued for deletion (from code; block deletion was not run).
> h3. Reproduction
> PASS: [^TestBugCR5HsyncMpuComplete.java] ({{hadoop-ozone/integration-test}}), 
> public client APIs on a mini cluster.
> h3. Suggested fix
> In {{S3MultipartUploadCompleteRequest}}, for both layouts, when 
> {{keyToDelete}} carries {{HSYNC_CLIENT_ID}}, look up that writer's open entry 
> and add {{OVERWRITTEN_HSYNC_KEY}} in the same transaction, and have the 
> response persist it. Whether such a complete should be rejected instead of 
> fencing the writer is a product question.
> h3. Patch
> [^CR-5-mark-hsync-open-key-overwritten-by-mpu-complete.patch], against 
> 20e6a1c0f6039248373efd3eb1d7f2afcf7f1535. It also applies to master at 
> 9c6bee807c8.
> When the entry being replaced carries {{HSYNC_CLIENT_ID}}, the request looks 
> up that writer's open key ({{getOpenFileName}} for FSO, {{getOpenKey}} 
> otherwise), adds {{OVERWRITTEN_HSYNC_KEY}} to the open table cache and hands 
> the entry to the response, which writes it in the same batch. This is the 
> handling the commit requests apply to a normal overwrite, so the writer's 
> later hsync or close is rejected with {{KEY_NOT_FOUND}} and 
> {{OpenKeyCleanupService}} removes the flagged open key. The marking sits 
> after the last check that can reject the complete. The response constructors 
> gain two parameters.
> Covered by {{testOverwrittenHsyncKeyIsMarked}} in the existing 
> {{TestS3MultipartUploadCompleteRequest}} (inherited by the FSO variant), 
> which fails without the change because the open key lacks 
> {{overwrittenHsyncKey}}. The multipart request and response unit suites (122 
> tests) and {{TestHSync}} (42 tests) pass, checkstyle is clean. Run against 
> the fix, the attached reproduction's stale hsync and stale close are rejected 
> with "is already deleted/overwritten". The FSO multipart mini cluster suite 
> was not run.
> Found by TLA+ model checking and code review of the OM FSO namespace mutation 
> paths under HDDS-15926, on commit 20e6a1c0f6039248373efd3eb1d7f2afcf7f1535. 
> Checked against HDDS issues and apache/ozone pull requests for duplicates 
> before filing. The attached patch is a proposal for review. Generated with 
> Specula (Claude Opus 5.5).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to