Hi! Thank you for your answer.
We updated *.ring.gz files on swift-proxy nodes and rebooted them. After that the problem was solved. All HEAD validation requests returned 2XX.
I think we should have done this after rebuilding the rings, but we didn't.
From: Clay Gerrard <clay.gerrard@gmail.com>
Sent: Thursday, August 4, 2022 6:43 PM
To: Komarov, Aleksandr <aleksandr.komarov@itglobal.com>
Cc: openstack-discuss@lists.openstack.org
Subject: Re: Large files multipart upload fails - OpenStack Object Storage (swift)
Those logs are curious.
After uploading file-segments, the final request to create a static large object manifest will validate all of the referenced segments with HEAD requests. All the referenced SLO segments have to return a successful 2XX response before
the manifest object will be created.
I can see you included the partial logs from transaction tx30e82374b98845bab6883-0062e7d225 and txf09676de38964ca299b77-0062e7dcc8 - but it's not entirely clear what happened between the object-server PUT that created the file-segment object
(response 201) and the HEAD that failed (response 404).
It appears both requests went to the same node (swift0-1-object01) and device (/mpathc) - so unless the file was deleted (or expired, or corrupted, or rebalanced) I would not expect the 404 response. Can you check on the file-segment object
AFTER the SLO validation fails? Does it keep returning 404? Where did it go?!
On Wed, Aug 3, 2022 at 12:26 PM Komarov, Aleksandr <aleksandr.komarov@itglobal.com> wrote:
Hi to all!
Please suggest how to fix the situation.
When uploading files larger than 100GB, at the stage of multipart-manifest validation, we get 404 error for some segments that were previously uploaded successfully. As a result, the client receives a 400 response. Uploading a large file is not possible.
Logs:
Aug 1 13:18:30 swift01-object01 object-server: IP - - [01/Aug/2022:13:18:30 +0000] "PUT /mpathc/12130/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/000
00032" 201 - "PUT http://domain-name/v1/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/00000032" "tx30e82374b98845bab6883-0062e7d225" "proxy-server 8367" 128.7641 "-" 21577 0
Aug 1 13:18:30 swift01-object01 container-server: IP - - [01/Aug/2022:13:18:30 +0000] "PUT /mpathb/952/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/00
000032" 201 - "PUT http://domain-name/mpathe/12130/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/00000032" "tx30e82374b98845bab6883-0062
e7d225" "object-server 24710" 0.0005 "-" 13211 0
Aug 1 14:01:46 swift01-object01 object-server: IP - - [01/Aug/2022:14:01:46 +0000] "HEAD /mpathc/12130/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/00000032" 404 - "HEAD http://domain-name/v1/AUTH_5affc785b3454cddb2d1f69ce62b4441/bucket/.file-segments/150.file/00000032" "txf09676de38964ca299b77-0062e7dcc8" "proxy-server 8367" 0.0003 "-" 21579 0
At the same time, some segments successfully found. With files less than 50GB everything is fine.
--
Clay Gerrard