mirror of
https://github.com/versity/versitygw.git
synced 2026-09-09 09:36:07 +00:00
niksis02
d03a33110d
This PR optimizes multipart upload checksum handling. When a checksum algorithm/type is specified at multipart-upload initiation, each `UploadPart` request computes, validates, and stores the corresponding part checksum. During `CompleteMultipartUpload`, the final checksum is derived either via composite checksum calculation or by composing the CRC-family checksums. When **no** checksum algorithm is specified during multipart-upload initiation, each `UploadPart` may supply a different checksum algorithm for data-integrity verification. To support this scenario, a new mechanism has been implemented: for every `UploadPart`, a **crc64nvme** checksum is always computed. * If the client uses crc64nvme for the part upload, a single hash reader is used. * Otherwise, two hash readers are used—one for crc64nvme and one for the user-provided checksum. The crc64nvme value is stored in part xattrs under `user.part-crc64nvme` and later used during `CompleteMultipartUpload` as a composable checksum source. In `CompleteMultipartUpload`, the hash reader is entirely removed; the gateway no longer re-reads part data to compute the final checksum. The logic now follows two distinct paths: 1. **Checksum algorithm/type specified at MP initiation** * All required per-part checksums have already been stored. * If the checksum type is `FULL_OBJECT`, the gateway uses the composable path. * If the type is `COMPOSITE`, the gateway follows the checksum-combining path. 2. **No checksum algorithm specified at MP initiation** * The gateway loads the stored per-part `crc64nvme` values and composes them to compute the final checksum. The previous `composableCRC` check has been removed because all `FULL_OBJECT` algorithms are inherently composable (`crc32`, `crc32c`, `crc64nvme`). Validation now relies solely on `checksum.Type`.