Open Stack

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 at gmail.com>
Sent: Thursday, August 4, 2022 6:43 PM
To: Komarov, Aleksandr <aleksandr.komarov at itglobal.com>
Cc: openstack-discuss at 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 at itglobal.com<mailto:aleksandr.komarov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220805/f6ae8e28/attachment.htm>