instead of c_str(), this should iterate over the bufferlist buffers. it may not alrady be a contiguous buffer and c_str() might trigger an expensive rebuild().

BTW this could be added as a bufferlist member, next to crc32c(). I'm not sure that's really where we want it long term, but they two can move together.

hmm, maybe an implementation that adds a type sha1_digest_t (that's 128 or 160 or however many bits), and an operator<< and to_str() method that renders the usual hex string...

I agree. I will fix it as your comment.

Out of curiosity, why did you choose SHA1 and not XXHASH as the fingerprint?

@mykaul SHA1 is just one of option. I'm focusing on dedup operations such as flushing, reference counting. But, as s future work, I will add other hash algorithms.

the source is this object, not the target object (named as the sha1 hash)

Right.

This doesn't seem like the place to add it. REDIRECT means the whole object is elsewhere, CHUNKED means pieces of it are elsewhere. Dedup seems like a particular case of either. Can we stick with CHUNKED here? Some chunks maybe deduped chunks, some not; some may be refcouned, some not. The current types already allow us to express that.

Right. Thanks for your comment.

This seems like the important addition. It feels like a "policy" or preference, though: it does't tell us anything about the existing chunks (which may or may not use this hash, or any hash), only what we ought to do with any new chunks.

In fact, do we need to persist this at all?

@liewegas This is post-dedup, which means the fingerprint is not generated when client's data is come. The fingerprint will be generated at flushing step. So, we need to keep fingerprint info such as sha1, sha256.
Without fingerprint info, how do we know which fingerprint method is used?

i would add clear_flags() { flags = 0; } and set_flagss(cflag_t t) { flags = t; }

ok

i don't understand why this is helping. and regardless, i don't think we should be special casing something like this in the generic OP_CALL case!

@liewegas
Let assume that we flush the chunked object.
Operations look like below

• op[2] = "write op", "chunk_get"

Write op will make a new object, but the object will not be stored on filesystem yet when chunk_get is called. So, chunk_get will fail and it receives ENOENT. In this case, we need to use chunk_set instead of chunk_get because chunk_get read existing value first and then add a new value.

To handle this case, I think there are two solutions. First is making a new OP such as CEPH_OSD_OP_WRITE_WITH_REF. Second is adding a special case as above.

What is your opinion?

pool_opts_t might be a better choice for this?

I think this should be a pool property set via 'osd pool set '. Look at something like 'compression_mode' as a model

ok

This logic looks right, but I think this should live in the same class as the GET/PUT.

In fact, now that I think about it, since we already have a specialized GET/PUT method (for chunks) that is different than the regular refcount behavior, perhaps we should create a new class calls 'cas' that collects all of these methods for managing the objects in the cas pool: WRITE_OR_GET, PUT, and eventually things like enumerating backreferences to support scrub, etc. That will also let us collect the user interface into a cls_cas_client.h (or whatever) for non-tiering users of the CAS pool (for example, we expect that RGW will write chunks directly into the cas tier).

@liewegas I agree. A new class call is right way. I'll rebase this commit.

I think we should aim to have chunk_write_or_get, chunk_put, and chunk_read_refcount all in the same cls. When I suggested 'cas' I expected them all to be there, but I forgot that the manifest can also refcount a non-cas object.

The main thing that worries me is that the existing methods in cls_refcount are already used by rgw and we have to be careful not to break them. On the other hand, the refcounts I expect for the cas objects are a bit different, where I expect we'll have some objects will millions of refs and we want to do some clever things with the way those are efficiently represented and scrubbed. This makes me want a clean cls_cas... except for the non-fingerprint objects that aren't actually content-addressibly named. Maybe cls_chunk captures the spirit of both? And lets us pull all of the chunk refcounting into a single class without recursively calling into other cls_refcount methods.

I'm sorry to keep moving the goal posts around on this! If you want we can sketch this out in a bit more detail first before adjusting the code again. The main thing I want to ensure is that other consumers of the cas pool (besides the tiering code... probably rgw in the nearish future) have a simple and clean interface to consume.

nit: can we call this sha1_digest_t (fp == fingerprint i assume, but digest is clearer)

I'm not sure that the bool valid is necessary. The default ctor can just zero the sha1, and if we really need to represent an undefined value we can use boost::optional<sha1_digest_t>?

= {0}