Suppose we start with the following in the cache pool:
30:[29,21,20,15,10,4]:[22(21), 15(15,10), 4(4)]+head
The object doesn't exist at 29 or 20.
First, we flush 4 leaving the backing pool with:
3:[]+head
Then, we begin to flush 15 with a delete with snapc 4:[4] leaving the
backing pool with:
4:[4]:[4(4)]
Then, we finish flushing 15 with snapc 9:[4] with leaving the backing
pool with:
9:[4]:[4(4)]+head
Next, snaps 10 and 15 are removed causing clone 10 to be removed leaving
the cache with:
30:[29,21,20,4]:[22(21),4(4)]+head
We next begin to flush 22 by sending a delete with snapc 4(4) since
prev_snapc is 4 <---------- here is the bug
The backing pool ignores this request since 4 < 9 (ORDERSNAP) leaving it
with:
9:[4]:[4(4)]
Then, we complete flushing 22 with snapc 19:[4] leaving the backing pool
with:
19:[4]:[4(4)]+head
Then, we begin to flush head by deleting with snapc 22:[21,20,4] leaving
the backing pool with:
22[21,20,4]:[22(21,20), 4(4)]
Finally, we flush head leaving the backing pool with:
30:[29,21,20,4]:[22(21*,20*),4(4)]+head
When we go to flush clone 22, all we know is that 22 is dirty, has snaps
[21], and 4 is clean. As part of flushing 22, we need to do two things:
1) Ensure that the current head is cloned as cloneid 4 with snaps [4] by
sending a delete at snapc 4:[4].
2) Flush the data at snap sequence < 21 by sending a copyfrom with snapc
20:[20,4].
Unfortunately, it is possible that 1, 1&2, or 1 and part of the flush
process for some other now non-existent clone have already been
performed. Because of that, between 1) and 2), we need to send
a second delete ensuring that the object does not exist at 20.
Fixes: #9054
Backport: firefly
Related: 66c7439ea0
Signed-off-by: Samuel Just <sam.just@inktank.com>
Because erasure-plugin has default k/m and can autotune if k or m
invalid. Check k/m they are the same as we want.
Signed-off-by: Ma Jianpeng <jianpeng.ma@intel.com>
In-flight cache reads were not previously counted against
new cache read requests, which could result in very large
cache usage. This effect is most noticeable when writing
small chunks to a cloned image since each write requires
a full object read from the parent.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Otherwise it is not found and the real cause obscured by the test
setup. The thread returns immediately and the timeout test sometime
fails.
http://tracker.ceph.com/issues/9368Fixes: #9368
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Github shows up a `guidelines for contributing` while opening a new pull
request for any repository with a CONTRIBUTING file at the repo
root, which allows for a quick overview to contribute to the
repository.
Currently this file just links to the Submitting Patches and the
documentation start guide.
Signed-off-by: Abhishek Lekshmanan <abhishek.lekshmanan@gmail.com>
