Without this, the same seed is used each time, so multiple runs
of bench-write with the same parameters have the same I/O pattern.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Use int instead of bool for the callback, and make it represent
whether the data exists, rather than the opposite, since callers
are likely to test for whether it's data instead of whether its zeroes.
Change the return value to 0, since an int64_t will wrap around
for large reads, and there's no value in reporting the length
read when it will always be the length requested clipped to the
size of the image.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
safe_read() just protects against EINTR, and may return less data than
requested if it reaches the end of the file. Use safe_read_exact() to
make sure we get the right amount of data.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
This will be jumpy since changed extents probably aren't evenly
distributed, but it's better than nothing.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
We were using the internal CEPH_NOSNAP and CEPH_SNAPDIR constants, and
defining a clone_info_t::HEAD (with a different value). The docs were
referrring to the internal constant names.
Instead, define librados constants (C and C++) with the same values as the
internal types.
Note that this changes the clone_info_t::HEAD value from -1 to -2 so that
it now matches the internal type.
Signed-off-by: Sage Weil <sage@inktank.com>
This code is confusing because we are moving back and forth between
image offsets, "buffer" offsets (image offsets relative to off), and
object offsets. Fix the math.
Signed-off-by: Sage Weil <sage@inktank.com>
If we have a parent image, and the reference is from snap 0 (beginning of
time) we need to look at the diff on the parent from the beginning of time
and report that when we get an ENOENT.
Signed-off-by: Sage Weil <sage@inktank.com>
Stress test that does io on an image while we are mirroring a diff from
earlier snaps to a second copy. At the end, verify that all snaps have
matching content.
Signed-off-by: Sage Weil <sage@inktank.com>
Export a diff of an image from a previous snapshot to a file (or stdout).
Import a diff and apply it to an image, and then create the ending
snapshot.
Signed-off-by: Sage Weil <sage@inktank.com>
Implement a diff_iterate() method that will iterate over an image and
report which extents vary between two snapshots (or a snapshot and the
head). The callback gets an extent and a flag indicating whether it is
full of data or is known to be zero in the ending snapshot.
Signed-off-by: Sage Weil <sage@inktank.com>
We need to return the list of snaps that each clone is defined for, not
the list of snaps we know may or may not exist globally over a similar
interval. This requires looking at the clone's obc, unfortunately.
Signed-off-by: Sage Weil <sage@inktank.com>
The list_snaps operation needs to look at the SnapSet, and is logically
querying all revisions of the object. Make requests to SNAPDIR be
read-only, and grab the head or snapdir obc transparently (whichever one
exists). This allows us to list snaps when, say, the head does not
exist, but there are in fact snaps.
Signed-off-by: Sage Weil <sage@inktank.com>
If there is a sequence of snaps 1, 2, 3, 4, 5, and we have a clone
2 with [1,2], and the head reflects content at snap times [3,4,5], then
the snap_list should return
clone 2 snaps [1,2]
head snaps
seq 2
because it never saw a write after snap 2, and therefor has the same
content currently as it did in snaps 3,4,5. If the SnapSet on the
object lists snaps 3,4,5, and the head exists, it actually means the
object was deleted between 2 and 3, and was recreated after 5:
clone 2 snaps [1,2]
head snaps []
seq 5
The key to telling the two situations apart is the seq number on the
SnapSet (now included in the list_snaps reply) that tells us when the
last update was.
Signed-off-by: Sage Weil <sage@inktank.com>
It is important to know the latest seq that the object has seen in order
to tell if a response like
clone 2 snaps=[1,2]
clone head snaps=[]
was untouched before a hypothetical snap 3, or deleted prior to snap 3,
and then recreated+modified after.
Signed-off-by: Sage Weil <sage@inktank.com>
