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: Fri, 9 Jul 2010 14:06:11 -0400 [thread overview]
Message-ID: <20100709180611.GA19808@redhat.com> (raw)
In-Reply-To: <yq1eifc1uzo.fsf@sermon.lab.mkp.net>
On Fri, Jul 09 2010 at 12:27pm -0400,
Martin K. Petersen <martin.petersen@oracle.com> wrote:
> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
>
> Mike> Turns out that this LUN has a 4K granularity requirement (will
> Mike> fail the WRITE SAME if the granularity requirements are not met).
>
> That's lame. The devices I've been working with just ignore the
> portions of the block range that are not aligned / do not constitute
> entire blocks.
What is really lame is this LUN also doesn't have the correct
discard_granularity!
# cat /sys/block/sda/queue/discard_granularity
512
> I've had the following patch kicking around in my tree for a while. It
> does not yet handle offset discard alignment, though.
OK, won't help us for this LUN but thanks.
I'm left wondering whether the higher level that is discarding a
particular large region (say blkdev_issue_discard's loop) should also be
trained about discard alignment too. That way the discard requests are
submitted properly aligned and they aren't reduced (leaving holes, like
your patch could do) -- except for the last discard in a sequence, which
could be reduced if its granularity is wrong.
No idea if the above will make sense to others ;)
Mike
next prev parent reply other threads:[~2010-07-09 18:06 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
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 [this message]
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=20100709180611.GA19808@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.