Hannes,
On 2/10/17 01:07, Hannes Reinecke wrote:
>> +/*
>> + * CRC32
>> + */
>> +static u32 dmz_sb_crc32(u32 crc, const void *buf, size_t length)
>> +{
>> + unsigned char *p = (unsigned char *)buf;
>> + int i;
>> +
>> +#define CRCPOLY_LE 0xedb88320
>> +
>> + while (length--) {
>> + crc ^= *p++;
>> + for (i = 0; i < 8; i++)
>> + crc = (crc >> 1) ^ ((crc & 1) ? CRCPOLY_LE : 0);
>> + }
>> +
>> + return crc;
>> +}
>> +
> Why do you insist on your own CRC32 implementations?
> Don't we have enough already?
Indeed. I will change this to use existing kernel API.
> Have you looked at using dm-kcopyd for doing the reclaim?
> What's inhibiting you from using it?
I did look at it, and I did like it very much. It would be much more
simple to use than open coding everything like I did. But the problem is
that while the read part is fine, the write part is not. The reason is
that most of the time, the zone being reclaimed is badly fragmented
(valid blocks all over the place in the zone). Reading those valid
blocks with kcopyd is fine, but when moving them to the target zone, the
overall write sequence MUST be sequential, which means that
blkdev_issue_zeroout calls must be inserted between non sequential
regions (the indirection system is per zone, not per block, so the
relative offsets of the blocks read in the zone being reclaimed must be
preserved in the destination zone).
I could modify kcopyd_copy to do this zeroout insertion of course. In
fact, I think that would be the better approach. But I think that can be
done later, once/if Mike accepts dm-zoned. Or I could re-submit dm-zoned
together with a patch for kcopyd_copy.
Mike,
Any advice on which approach is best/more acceptable for you ?
Thanks !
Best regards.
--
Damien Le Moal, Ph.D.
Sr. Manager, System Software Research Group,
Western Digital Corporation
Damien.LeMoal@xxxxxxx
(+81) 0466-98-3593 (ext. 513593)
1 kirihara-cho, Fujisawa,
Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com
