(2010/04/12 16:24), Trond Norbye wrote:
>
> On 11. apr. 2010, at 17.56, KaiGai Kohei wrote:
>>
>> It seems to me the new get_item_info() interface intends to contain various
>> kind of properties more than bare threes (value, cas and expired time),
>> because we can easily expand the number of 'struct iovec value[]' in the
>> new item_info.
>>
>
> That's not what the iovector is intended for. The network protocol specifies
> the attributes we use for an item (we need a new network protocol to encode
> other attributes), so that wasn't what I planned to use the iovector for.
> The usecase for the iovector is to allow the engines to store their items as
> multiple fragments (and not have to concatenate them into a single object
> before returning it to the core. (please note that currently the iovector
> is _never_ bigger than one element, but I'm planning to fix that this week.
Sorry, I'm a bit confusing.
Are you saying the data fragments are not necessary to be placed on the
continuous region in physically?
If so, it seems to me allocate() method needs to be revised to take an
arguments to indicate the number of fragments (with their lengths) on
allocation time?
However, it seems to me the following description introduces all the
needed region is allocated on the allocation time at once, then the data
region will be segmented into several chunks.
> The reason I didn't add that to the allocate function is that it would
> complicate the state machine in the core. I would think that most engine
> writers could live with allocating a continuous segment during allocation,
> and then store it in multiple segments when the user calls store().
BTW, here is a point I missed it.
Currently, do_add_delta() and do_store_item() with APPEND/PREPEND option
assume the data field only contains the original data. So, if we inject
extra attributes into the data region, it performs unexpectedly.
For example, if we append {key="aaa", value="mokemoke"} after the
{key="aaa", value="fugafuga"}, and both have "classified\0" as security
label, it will concatenate them without eliminating extra attributes,
like {key="aaa", value="fugafugaclassified\0mokemoke"}.
^^^^^^^^^^^^
So, we need to inform secondary module where is the data segment and where
is the extra attributes of items, even if the secondary module allocate
data region in flat.
Thanks,
--
KaiGai Kohei <kai...@ak.jp.nec.com>
--
To unsubscribe, reply using "remove me" as the subject.
