From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Monakhov Dmitri <dmonakhov@openvz.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 4 of 7] block: bio data integrity support
Date: Mon, 09 Jun 2008 11:05:13 -0400 [thread overview]
Message-ID: <yq1wskyk5sm.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <m3od6duwwg.fsf@dmon-lap.sw.ru> (Monakhov Dmitri's message of "Sat\, 07 Jun 2008 18\:45\:03 +0400")
>>>>> "DM" == Monakhov Dmitri <dmonakhov@openvz.org> 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
next prev parent reply other threads:[~2008-06-09 15:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-07 4:55 [PATCH 0 of 7] Block/SCSI Data Integrity Support Martin K. Petersen
2008-06-07 4:55 ` [PATCH 1 of 7] lib: Add support for the T10 Data Integrity Field CRC Martin K. Petersen
2008-06-07 4:55 ` [PATCH 2 of 7] block: Globalize bio_set and bio_vec_slab Martin K. Petersen
2008-06-10 18:55 ` Jeff Moyer
2008-06-07 4:55 ` [PATCH 3 of 7] block: Find bio sector offset given idx and offset Martin K. Petersen
2008-06-09 16:07 ` Jeff Moyer
2008-06-09 16:15 ` Martin K. Petersen
2008-06-10 19:02 ` Jeff Moyer
2008-06-07 4:55 ` [PATCH 4 of 7] block: bio data integrity support Martin K. Petersen
2008-06-07 14:45 ` Monakhov Dmitri
2008-06-09 15:05 ` Martin K. Petersen [this message]
2008-06-10 20:52 ` Jeff Moyer
2008-06-11 4:05 ` Martin K. Petersen
2008-06-11 17:41 ` Jeff Moyer
2008-06-07 4:55 ` [PATCH 5 of 7] block: Block/request layer " Martin K. Petersen
2008-06-08 4:27 ` Greg KH
2008-06-09 15:06 ` Martin K. Petersen
2008-06-07 4:55 ` [PATCH 6 of 7] scsi: Support devices with protection information (DIF) Martin K. Petersen
2008-06-07 4:55 ` [PATCH 7 of 7] Support for SCSI disk (SBC) Data Integrity Field Martin K. Petersen
2008-06-10 14:41 ` [PATCH 0 of 7] Block/SCSI Data Integrity Support Jeff Moyer
2008-06-10 15:28 ` Martin K. Petersen
2008-06-10 18:49 ` Jeff Moyer
2008-06-10 20:47 ` Martin K. Petersen
2008-06-10 20:53 ` Jeff Moyer
2008-07-17 13:55 ` Mike Snitzer
2008-07-17 15:35 ` Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq1wskyk5sm.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=dmonakhov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome