Util-Linux package development
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Tom Yan <tom.ty89@gmail.com>
Cc: Karel Zak <kzak@redhat.com>,
	util-linux@vger.kernel.org,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: optimal io size / custom alignment
Date: Tue, 16 Jun 2015 13:08:41 -0400	[thread overview]
Message-ID: <yq1zj3zfuna.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <CAGnHSEm6wDq_EjJXYwqV2Tt2868DbR0bNRYvevhN1AM4qJpaPw@mail.gmail.com> (Tom Yan's message of "Tue, 16 Jun 2015 13:20:37 +0800")

>>>>> "Tom" == Tom Yan <tom.ty89@gmail.com> writes:

Tom> From the adapter/drive I have, it is the same as the "Maximum
Tom> transfer length" and they seem to be simply limits of SCSI "WRITE
Tom> SAME (10/16)" command:

The two values have nothing to do with each other. They just happen to
be the same in your case (65535 is the maximum block count for the WRITE
SAME(10) command).

Tom> [tom@localhost ~]$ sudo sg_inq -p 0xb0 /dev/sdb VPD INQUIRY: Block
Tom> limits page (SBC) Maximum compare and write length: 0 blocks
Tom> Optimal transfer length granularity: 1 blocks Maximum transfer
Tom> length: 65535 blocks Optimal transfer length: 65535 blocks

Your device sets the transfer length granularity to 1 logical block and
the optimal transfer length to 65535 logical blocks. If it then reports
a 4096-byte physical block size in response to READ CAPACITY(16) then
it's clearly on crack.

There's only so much we can do about devices that report garbage.

Also, the kernel only reports things. It is up to Karel to decide
whether to sanity check the values before he uses them.

I would probably err on the side of trusting the physical block size
reporting more than anything seeded from the Block Limits VPD. And in
this case, assuming the alignment offset is reported to be 0, I guess
one could entertain aligning to the nearest 4K boundary. But on the
other hand it'll quickly get hairy to have to maintain this kind of
heuristics.

The best fix, of course, is to complain to the manufacturer of your
broken widget and hope for a firmware upgrade. Failing that, adjust your
partitions manually.

Tom> The thing is, why any io/transfer size/length should be considered
Tom> when it comes to partition alignment? From what I understand,
Tom> partition alignment is only to make sure partition starts at
Tom> physical boundaries of the disk because of the mismatch between
Tom> logicial sector (512 bytes) and physical sectors (4096 bytes) or
Tom> pages/erase blocks of SSDs.

For RAID it makes a big difference to ensure the partition is aligned on
a stripe boundary.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2015-06-16 17:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-13 14:52 optimal io size / custom alignment Tom Yan
2015-06-15 13:31 ` Karel Zak
2015-06-16  5:20   ` Tom Yan
2015-06-16  5:37     ` Tom Yan
2015-06-16  9:43     ` Karel Zak
2015-06-16 10:22       ` Tom Yan
2015-06-16 17:08     ` Martin K. Petersen [this message]
2015-06-16 19:26       ` Tom Yan
2015-06-16 21:28         ` Martin K. Petersen
2015-06-17  9:49           ` Tom Yan
2015-06-18 21:01             ` Martin K. Petersen
2015-06-20 16:01               ` Tom Yan
2015-06-21  0:12                 ` Martin K. Petersen
2015-06-22 14:32                 ` Alan Stern
2015-07-12  4:19   ` optimal io size / custom alignment -- caution on custom aligns Linda Walsh

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=yq1zj3zfuna.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=kzak@redhat.com \
    --cc=tom.ty89@gmail.com \
    --cc=util-linux@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