No, but I've seen it in RadosGW too. I've been meaning to post about it. I get about ten a day, out of about 50k objects/day.
Also note the 0 byte filesize and the lack of MD5 checksum. What I find interesting is that I can fix this by downloading the file and uploading it again. The filename is a SHA256 hash of the file contents, and the file downloads correctly every time. I never see this in my replication cluster, only the primary cluster.
31 seconds is a big spread between the initial PUT and the second PUT. The file is only 43k, so it'll be using the direct PUT, not multi-part upload. I haven't verified this for all of them.
clewis@clewis-mac ~ (-) $ s3cmd ls s3://live32/ | grep '1970-01' | head -1
1970-01-01 00:00 0 s3://live-32/39020f17716a18b39efd8daa96e8245eb2901f353ba1004e724cb56de5367055
The access look looks kind of interesting for this file:
192.168.2.146 - - [23/Mar/2015:20:11:30 -0700] "PUT /39020f17716a18b39efd8daa96e8245eb2901f353ba1004e724cb56de5367055 HTTP/1.1" 500 722 "-" "aws-sdk-php2/2.7.20 Guzzle/3.9.2 curl/7.40.0 PHP/5.5.21" "live-32.us-west-1.ceph.cdlocal"
192.168.2.146 - - [23/Mar/2015:20:12:01 -0700] "PUT /39020f17716a18b39efd8daa96e8245eb2901f353ba1004e724cb56de5367055 HTTP/1.1" 200 205 "-" "aws-sdk-php2/2.7.20 Guzzle/3.9.2 curl/7.40.0 PHP/5.5.21" "live-32.us-west-1.ceph.cdlocal"
192.168.2.146 - - [23/Mar/2015:20:12:09 -0700] "HEAD /39020f17716a18b39efd8daa96e8245eb2901f353ba1004e724cb56de5367055 HTTP/1.1" 200 250 "-" "aws-sdk-php2/2.7.20 Guzzle/3.9.2 curl/7.40.0 PHP/5.5.21" "live-32.us-west-1.ceph.cdlocal"
There's nothing in radosgw.log at the time of the 500.
On Wed, Apr 1, 2015 at 2:42 AM, Jimmy Goffaux <jimmy@xxxxxxxxxx> wrote:
English Version :
Hello,
I found a strange behavior in Ceph. This behavior is visible on Buckets (RGW) and pools (RDB).
pools:
``
root@:~# qemu-img info rbd:pool/kibana2
image: rbd:pool/kibana2
file format: raw
virtual size: 30G (32212254720 bytes)
disk size: unavailable
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
snap2014-08-26-kibana2snap2014-08-26-kibana2 30G 1970-01-01 01:00:00 00:00:00.000
snap2014-09-05-kibana2snap2014-09-05-kibana2 30G 1970-01-01 01:00:00 00:00:00.000
``
As you can see the all dates are set to 1970-01-01 ?
Here's the content of a JSON file in a bucket.
``
{'bytes': 0, 'last_modified': '1970-01-01T00:00:00.000Z', 'hash': u'', 'name': 'bab34dad-531c-4609-ae5e-62129b43b181'}
```
You can see this is the same for the "Last Modified" date.
Do you have any ideas?
French Version :
Bonjour,
J'ai un comportement anormal sur ceph. J'ai des problèmes sur les
Buckets(RGW) et les pools(RDB).
Pools :
``
root@:~# qemu-img info rbd:pool/kibana2
image: rbd:pool/kibana2
file format: raw
virtual size: 30G (32212254720 bytes)
disk size: unavailable
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
snap2014-08-26-kibana2snap2014-08-26-kibana2 30G 1970-01-01 01:00:00 00:00:00.000
snap2014-09-05-kibana2snap2014-09-05-kibana2 30G 1970-01-01 01:00:00 00:00:00.000
``
En effet la DATE est à 1970-01-01 ???
Pour les Buckets voici le retour JSON d'un fichier dans un bucket :
``
{'bytes': 0, 'last_modified': '1970-01-01T00:00:00.000Z', 'hash': u'', 'name': 'bab34dad-531c-4609-ae5e-62129b43b181'}
```
Pareil le Last Modified est à 1970-01-01..
Avez-vous des idées ?
--
Jimmy Goffaux
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
