Created attachment 979843 [details] curl output showing the request fine at 512K and failing with 1 byte more Description of problem: Making a request for partial content greater than 512K of an object, using the swift api, fails with the last byte remaining. Version-Release number of selected component (if applicable): This has been seen on the radosgw both versions 0.80.6 and 0.80.7 How reproducible: Problem has been seen on two different clusters and mentioned on the ceph mailing list. http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-January/026730.html Steps to Reproduce: 1. Upload an object greater than 512K in size, using swift, to the radosgw 2. Attempt to download a portion of the object with a range header greater than 512K in the request Actual results: Failure to successfully download the file. Expected results: File downloaded without error. Additional info: See attachment for further details.
Pushed a fix to wip-105530-firefly: https://github.com/ceph/ceph/commit/755950104eba68e25bd09d9e6088a2ff6b406b88
Looks like fixed upstream if I read Yehuda correctly. Not clear why this was not merged in 1.2 since it is in Firefly upstream since January. Yehuda, please set level_ack to + if this is OK for Stockwell.
This is fixed in 0.80.9.
(In reply to Federico Lucifredi from comment #2) > Not clear why this was not merged in 1.2 since it is in Firefly upstream > since January. (It's because we haven't rebased the RH Ceph Storage product's 1.2 series to 0.80.9 yet.)
I'll clone this bug so we can make sure this fix lands in RHCeph 1.2.z as well.
QE ACKing the bug for 1.3.0.
Tested and verified on 1.3.0. Created an object with 600K size and made a GET request for partial content greater than 512K of an object. It worked successfully without an error. Container: test-bucket Object: test.txt Content Type: binary/octet-stream Content Length: 614400 Data sets with partial request > 512k # curl -v -X GET 'http://10.x.x.x/swift/v1/test-bucket/test.txt' -H 'Range: bytes=0-524288' -H "X-Auth-Token: AUTH_rgwtkxxx" > text * About to connect() to 10.x.x.x port 80 (#0) * Trying 10.x.x.x... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.x.x.x (10.x.x.x) port 80 (#0) > GET /swift/v1/test-bucket/test.txt HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 10.x.x.x > Accept: */* > Range: bytes=0-524288 > X-Auth-Token: AUTH_rgwtxxx > < HTTP/1.1 206 Partial Content < Content-Range: bytes 0-524288/614400 < Content-Length: 524289 < Accept-Ranges: bytes < Last-Modified: Mon, 15 Jun 2015 15:02:56 GMT < X-Timestamp: 1434380576 < etag: d22097bf4b8e31d2eeb5a7ee984c62ad < X-Object-Meta-mtime: 1434380553.383925 < Content-type: binary/octet-stream < { [data not shown] 100 512k 100 512k 0 0 8527k 0 --:--:-- --:--:-- --:--:-- 8677k * Connection #0 to host 10.x.x.x left intact # curl -v -X GET 'http://10.x.x.x/swift/v1/test-bucket/test.txt' -H 'Range: bytes=0-524300' -H "X-Auth-Token: AUTH_rgwtkxxx" > text * About to connect() to 10.x.x.x port 80 (#0) * Trying 10.12.27.11... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.x.x.x (10.x.x.x) port 80 (#0) > GET /swift/v1/test-bucket/test.txt HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 10.x.x.x > Accept: */* > Range: bytes=0-524300 > X-Auth-Token: AUTH_rgwtkxxx > < HTTP/1.1 206 Partial Content < Content-Range: bytes 0-524300/614400 < Content-Length: 524301 < Accept-Ranges: bytes < Last-Modified: Mon, 15 Jun 2015 15:02:56 GMT < X-Timestamp: 1434380576 < etag: d22097bf4b8e31d2eeb5a7ee984c62ad < X-Object-Meta-mtime: 1434380553.383925 < Content-type: binary/octet-stream < { [data not shown] 100 512k 100 512k 0 0 18.4M 0 --:--:-- --:--:-- --:--:-- 20.0M * Connection #0 to host 10.12.27.11 left intact
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1183