On 13. apr. 2010, at 01.17, KaiGai Kohei wrote:
>
> Rather than the server API to inform maximum number of fragments,
> it seems to me the get_item_info() should provides total number of
> fragments in the specified item, and the memcached core calls engine
> api to set up an iovector of the specified fragment of the item.
>
> If so, a part of intermediating module will be able to drop a part of
> the fragments which contains security context.
>
> Of course, a large number of iteration of append/prepend may make
> the data structure inefficient, so I think any mechanism to reorganize
> well hashed fragments...
>
I don't like the idea that the engine should be able to require the server to
support an arbitrary number of fragments. The core needs to allocate space for
the iovector for transfer of the item, so if we make this completely arbitrary
we cannot determine the memory usage we need for an item transfer.
>>> 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.
>>
>> If you're storing meta-data inside the real data of an item, you would just
>> have to add your own implementation for append/prepend where you do the
>> operation on the items and then try to call a cas set operation to the
>> engine.
>
> If we can store meta-data in a certain fragment, is it unnecessary to handle
> append/preprend and delta operations in the intermediating module?
>
I really don't want to force all engines to support storing attributes (or use
io vectors)
Trond
--
To unsubscribe, reply using "remove me" as the subject.
