2011/8/25 Yehuda Sadeh Weinraub <yehuda.sadeh@xxxxxxxxxxxxx>:
>>>>> + if (buf) {
>>>>> + dif = ofs-lastofs;
>>>>> + if (dif > 0) {
>>>>> + byte *tempbuf = (byte *) malloc(dif);
>>>>> + memset(tempbuf, 0, dif);
>>>>> + Hash->Update((const byte *) tempbuf, dif);
>>>>> + free(tempbuf);
>>>>> + }
>>>>> +
>>>>> + Hash->Update((const byte *) buf, len);
>>>>> + lastofs = ofs + len;
>>>>> + }
>>>>
>>>> Does this mean a file with a 100GB hole in it will make you malloc(100GB)?
>>>>
>>> That's in the read_iterate() callback. It wouldn't be called with
>>> anything larger than a single block size.
>>>
>>> Unless I'm somehow missing, it's still missing the holes. Now it just
>>> ignores them, it should be taking them into account as zero data.
>>
>> To my reading, that is *exactly* what the quoted code does -- it just
>> assumes that a hole can fit fully in RAM.
>>
> Oh, right, misread that snippet. The test should go the other way
> around; something like:
>
> byte *hashbuf = buf;
> byte *tempbuf = NULL;
> if (!buf) {
> tempbuf = (byte *) calloc(len);
> if (!tempbuf)
> return -ENOMEM;
> hashbuf = tempbuf;
> }
> Hash->Update((const byte *) hashbuf, len);
> free(tempbuf);
Of course you are right. Just skipping the holes would possibly lead
to large allocations, which is not a good idea. I will send an updated
patch...
Thanks,
Christian
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
