>>>>> "DM" == Monakhov Dmitri <dmonakhov@xxxxxxxxxx> writes: >> + 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. >> + >> + 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
