From: Mike Snitzer <snitzer@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Douglas Gilbert <dgilbert@interlog.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
linux-scsi@vger.kernel.org, James.Bottomley@suse.de, hch@lst.de,
axboe@kernel.dk
Subject: Re: scsi: convert discard to REQ_TYPE_FS instead of REQ_TYPE_BLOCK_PC
Date: Tue, 6 Jul 2010 22:19:43 -0400 [thread overview]
Message-ID: <20100707021943.GA13044@redhat.com> (raw)
In-Reply-To: <yq1ocek6pf4.fsf@sermon.lab.mkp.net>
On Tue, Jul 06 2010 at 9:39pm -0400,
Martin K. Petersen <martin.petersen@oracle.com> wrote:
> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
>
> >> That is 0x7fffff (over 8 million) blocks (4 GB) being unmapped in one
> >> operation! That may exceed the "maximum unmap lba count" field in the
> >> Block Limits VPD page. The latest SBC draft (sbc3r22.pdf) says that
> >> field applies to the SCSI UNMAP command and does not mention the
> >> WRITE SAME (16) command but that is probably an oversight.
>
> Maximum Unmap LBA Count > 0 (in combination with the descriptor count)
> are what indicate that the device server supports UNMAP.
>
> You could argue, then, that a Maximum Unmap LBA Count > 0 but a Maximum
> Unmap Descriptor Count of 0 would provide means to indicate the maximum
> range for WRITE SAME. But the T10 people I have talked to all agree
> that the LBA count for WRITE SAME is gated by the command's LBA count
> and nothing else. So no special casing for when the UNMAP bit is set.
> I.e. the max for WRITE SAME(16) is 32-bits times logical_block_size.
Ah, yes completely missed that fact that we're talking WRITE SAME(16)
yet I was looking at UNMAP limits.
>
> Mike> # cat /sys/block/sda/queue/discard_granularity
> Mike> 512
> Mike> # cat /sys/block/sda/queue/discard_max_bytes
> Mike> 4294966784
>
> Mike> I'll look to understand why 'discard_max_bytes' is so large for
> Mike> this LUN despite the standard Block limits VPD page not reflecting
> Mike> this.
>
> discard_max_bytes is 0xFFFFFFFF for WRITE SAME(16).
Seems discard_max_bytes = 0x7fffff * 512 = 4294966784
So mkfs.ext4's BLKDISCARD ioctl first issues a discard of
discard_max_bytes (via blkdev_issue_discard's loop) and it fails.
Question becomes: why did the request fail if the LUN supports WRITE
SAME(16) and its max is 0xFFFFFFFF?
Likely a question for the vendor but I'd first like to make sure it is
reasonable to expect this command to succeed.
Thanks,
Mike
next prev parent reply other threads:[~2010-07-07 2:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-06 7:01 [PATCH] scsi: convert discard to REQ_TYPE_FS instead of REQ_TYPE_BLOCK_PC FUJITA Tomonori
2010-07-06 21:31 ` Mike Snitzer
2010-07-06 23:40 ` Douglas Gilbert
2010-07-07 0:47 ` Mike Snitzer
2010-07-07 1:39 ` Martin K. Petersen
2010-07-07 2:19 ` Mike Snitzer [this message]
2010-07-07 3:35 ` Douglas Gilbert
2010-07-08 19:11 ` Mike Snitzer
2010-07-09 16:27 ` Martin K. Petersen
2010-07-09 18:06 ` Mike Snitzer
2010-07-09 16:22 ` Martin K. Petersen
2010-07-07 4:06 ` FUJITA Tomonori
2010-07-07 4:07 ` James Bottomley
2010-07-07 16:39 ` [PATCH] " Christoph Hellwig
2010-07-08 0:40 ` FUJITA Tomonori
2010-07-08 14:35 ` James Bottomley
2010-07-09 3:55 ` Christoph Hellwig
2010-07-09 4:42 ` FUJITA Tomonori
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=20100707021943.GA13044@redhat.com \
--to=snitzer@redhat.com \
--cc=James.Bottomley@suse.de \
--cc=axboe@kernel.dk \
--cc=dgilbert@interlog.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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;
as well as URLs for NNTP newsgroup(s).