01f6e86006
Sysmeta included with an object PUT persists with the PUT data - if an internal operation such as POST-as-copy during partial failure, or ssync with fast-POST (not supported), causes that data to be lost then the associated sysmeta will also be lost. Since object sys-meta persistence in the face of a POST when the original .data is unavailable requires fast-POST with .meta files the probetest that validates object sys-meta persistence of a POST when the most up-to-date copy of the object with sys-meta is unavailable configures an InternalClient with object_post_as_copy = false. This non-default configuration option is not supported by ssync and results in a loss of sys-meta very similar to the object sys-meta failure you would see with object_post_as_copy = true when the COPY part of the POST is unable to retrieve the most recently written object with sys-meta. Until we can fix the default POST behavior to make metadata updates without stomping on newer data file timestamps we should expect object sys-meta to be "very very best possible but not really guaranteed effort". Until we can fix ssync to replicate metadata updates without stomping on newer data file timestamps we should expect this test to fail. When ssync replication of fast-POST metadata update is fixed this test will fail signaling that the expected failure cruft should be removed, but other parts of ssync replication will still work and some other bugs can be fixed while we wait. Change-Id: Ifc5d49514de79b78f7715408e0fe0908357771d3 |
||
|---|---|---|
| .. | ||
| functional | ||
| probe | ||
| unit | ||
| __init__.py | ||
| sample.conf | ||