All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: dgilbert@interlog.com
Cc: mkp@mkp.net, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi_debug: add TPRZ support
Date: Mon, 23 Aug 2010 20:17:10 -0500	[thread overview]
Message-ID: <4C731D96.5000308@redhat.com> (raw)
In-Reply-To: <4C731B08.1060100@interlog.com>

Douglas Gilbert wrote:
> Eric,
> Now for a really serious issue: in sbc3r24
> TPRZ == "thin provisioning read zeros".
> SBC-3 uses the shorter variant of the plural of
> zero. [ACS-2 uses both zeros and zeroes :-)]
> 
> The reason I point that out (apart from trying to
> distract James B. from another dispute) is that
> you are introducing a new module option called
> "unmap_zeroes". I prefer the shorter form.

Ok, I think i was following Martin's lead there,
based on what's presented in sysfs:

queue/discard_zeroes_data

Believe it or not I thought about this ;)

> When I tried to combine your patch on top of Martin's
> I needed to do a hand merge (since I'm "gitless") onto
> lk 2.6.35 . Both of you picked almost the same lines
> to change. Attached is the result of my patch merge
> against lk 2.6.35 . It may not be tab clean.
> 
> With that combined patch I checked a real SSD that
> does TPRZ against the scsi_debug virtual SSD and it
> looked okay with my utilities.

Thanks, will look over your combined patch & let you know
if I see anything.

-Eric

> 
> SCSI WRITE SAME does have one interesting quirk that
> Martin may like to consider. If the "number of
> logical blocks" field is zero, then that implies write
> to the end of the LU!! Madness when you think about it.
> libata's SCSI WRITE SAME translation takes the zero
> number of LBs literally and does nothing I guess
> (when the UNMAP bit is given).
> 
> Doug Gilbert
> 
> 
> 
> On 10-08-23 03:24 PM, Eric Sandeen wrote:
>> Add TPRZ support to scsi_debug; i.e. return zero for
>> unmapped blocks.
>>
>> Rather than checking for unmapped blocks at
>> read time, this just zeroes them on the backing store
>> at unmap time so it behaves the same way.
>>
>> This also adds a module parameter to disable it, since
>> some SSDs have this behavior.
>>
>> Signed-off-by: Eric Sandeen<sandeen@redhat.com>
> 
> Acked-by: Douglas Gilbert <dgilbert@interlog.com>
> 


  reply	other threads:[~2010-08-24  1:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23 19:24 [PATCH] scsi_debug: add TPRZ support Eric Sandeen
2010-08-24  1:06 ` Douglas Gilbert
2010-08-24  1:17   ` Eric Sandeen [this message]
2010-08-24 19:22   ` 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=4C731D96.5000308@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dgilbert@interlog.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkp@mkp.net \
    /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.