>>>>> "DM" == Monakhov Dmitri <dmonakhov@openvz.org> writes:

quoted text
>> + nr_sectors = len / bi->tag_size;
>> +
>> + if (len % 2) + nr_sectors++;
DM> Seems i've missing something. What is purpose of this black magic?
DM> do you want just express following?  nr_sectors = (len +
DM> bi->tag_size - 1) / bi->tag_size;

Yep.  In the original DIF spec, only 2-byte tags were supported so the
check for an odd length was a fast and elegant solution.  But now that
I implemented Type 3 which has 6 bytes of tag space that's an invalid
assumption.  Fixed.


quoted text
>> +
>> + if (bi->sector_size == 4096) + nr_sectors >>= 3;

DM> Why here and later sector_size == 4096 is so special, what about
DM> 1k and 2k sect_sz? Do you want just transform value from 512 to
DM> bi->sectors_size?

Well, so only 512-byte DIF storage devices are currently available.
The whole industry is in the process of transitioning to 4KB sectors.
There will be no DIF devices with 1KB or 2KB sectors.

And even as it stands it's unclear that 4KB sectors are going to look
like they do in the current version of the spec.  It's going to be an
interoperability nightmare as it is now as the tag is attached to the
hardware sector size.  This means that it's still only 8 bytes of DIF
for a device with 4KB sectors (IOW, 4104 bytes and not 4160).  That
means that *two* protection buffers would have to be generated for -
say - a mirror with heterogeneous sector sizes.  And tagging won't
work as there's not the same space available for both drives of the
mirror.

The tag space problem also causes issues with RAID arrays exporting
512 byte sectors to the host but using drives with 4KB sectors in the
back.  Where is the array going to store the tags for the last 7 512
byte sectors?

So 4KB vs. DIF is up in the air at this point.  The current checks are
there because I've been messing with 4KB sector devices for other
reasons.  And technically they are in accordance with the current
spec.

-- 
Martin K. Petersen	Oracle Linux Engineering

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/