> "Christoph" == hch@infradead org writes:
Christoph> That's mostly because we don't support larger than 512 byte
Christoph> TRIM payloads yet..
I did add support for that a few years back but all hell broke loose and
we had to revert it. There were several drives that failed with more
than
On Wed, Jul 16, 2014 at 03:20:00PM -0400, Martin K. Petersen wrote:
> The block layer can only describe one contiguous block range in a
> request. My copy offload patches introduces the bi_special field that
> allows us to attach additional information to an I/O. I have
> experimented with doing
On Wed, Jul 16, 2014 at 03:20:00PM -0400, Martin K. Petersen wrote:
The block layer can only describe one contiguous block range in a
request. My copy offload patches introduces the bi_special field that
allows us to attach additional information to an I/O. I have
experimented with doing that
Christoph == hch@infradead org h...@infradead.org writes:
Christoph That's mostly because we don't support larger than 512 byte
Christoph TRIM payloads yet..
I did add support for that a few years back but all hell broke loose and
we had to revert it. There were several drives that failed with
> "James" == James Bottomley writes:
James> Well, your judgement: is this situation (support for UNMAP but
James> not for WRITE_SAME) in what is effectively a RAID driver (hv
James> drivers count as RAID) just a silly Microsoft one off?
I only recall seeing one or two devices that supported
> "Rob" == Elliott, Robert (Server Storage) writes:
Rob> WRITE SAME with the UNMAP bit set to one (and a few other
Rob> conditions) guarantees that the data is zeroed out, while the UNMAP
Rob> command is just a hint. They're not fully interchangeable. Which
Rob> semantics are implied by
On Wed, 2014-07-16 at 15:08 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> James> It's the code we identified in sd.c:read_capacity_16():
>
> That's there to support devices that implement thin provisioning but
> which predate the LBP VPD page. And thus have no
> "James" == James Bottomley writes:
James> It's the code we identified in sd.c:read_capacity_16():
That's there to support devices that implement thin provisioning but
which predate the LBP VPD page. And thus have no way to tell us their
preferred command variant.
James> If the inquiry
On Wed, 2014-07-16 at 14:45 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> >> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
> >> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
> >> does fix the problem at hand. That's
> "James" == James Bottomley writes:
>> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
>> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
>> does fix the problem at hand. That's why I went that route.
James> Hang on ... unless we apply Christoph or
nfradead.org;
> de...@linuxdriverproject.org; a...@canonical.com; k...@microsoft.com;
> sta...@vger.kernel.org; linux-s...@vger.kernel.org; oher...@suse.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, 2014-07-16 at 1
On Wed, 2014-07-16 at 13:47 -0400, Martin K. Petersen wrote:
> > "Christoph" == hch@infradead org writes:
>
> Christoph> Oh, we actually have devices that support WRITE SAME with
> Christoph> unmap, but not without? That's defintively a little strange.
>
> Yep :(
>
> There were several
On Wed, Jul 16, 2014 at 01:47:35PM -0400, Martin K. Petersen wrote:
> There were several SSDs that did not want to support wearing out flash
> by writing gobs of zeroes and only support the UNMAP case.
Given that SSDs usually aren't hard provisioned anyway that seems like
an odd decision. But
> "Christoph" == hch@infradead org writes:
Christoph> Oh, we actually have devices that support WRITE SAME with
Christoph> unmap, but not without? That's defintively a little strange.
Yep :(
There were several SSDs that did not want to support wearing out flash
by writing gobs of zeroes
On Wed, Jul 16, 2014 at 11:44:18AM -0400, Martin K. Petersen wrote:
> There are lots of devices out there that support WRITE SAME(10) or (16)
> without the UNMAP bit. And there are devices that support WRITE SAME w/
> UNMAP functionality but not "regular" WRITE SAME.
Oh, we actually have devices
> "hch" == hch@infradead org writes:
hch> read_capacity_16 calls sd_config_discard(sdkp, SD_LBP_WS16) if the
hch> LPBME bit is set. At least older SBC drafts left it wide open if a
hch> target supports WRITE SAME with UNMAP or UNMAP in this case.
Correct.
hch> So I think we'd still want a
On Wed, 2014-07-16 at 04:01 -0700, h...@infradead.org wrote:
> On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > > "KY" == KY Srinivasan writes:
> >
> > KY> Windows hosts do support UNMAP and set the field in the
> > KY> EVPD. However, since the host advertises SPC-2
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > "KY" == KY Srinivasan writes:
>
> KY> Windows hosts do support UNMAP and set the field in the
> KY> EVPD. However, since the host advertises SPC-2 compliance, Linux
> KY> does not even query the VPD page.
>
> >> If we
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
KY == KY Srinivasan k...@microsoft.com writes:
KY Windows hosts do support UNMAP and set the field in the
KY EVPD. However, since the host advertises SPC-2 compliance, Linux
KY does not even query the VPD page.
If we
On Wed, 2014-07-16 at 04:01 -0700, h...@infradead.org wrote:
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
KY == KY Srinivasan k...@microsoft.com writes:
KY Windows hosts do support UNMAP and set the field in the
KY EVPD. However, since the host advertises SPC-2
hch == hch@infradead org h...@infradead.org writes:
hch read_capacity_16 calls sd_config_discard(sdkp, SD_LBP_WS16) if the
hch LPBME bit is set. At least older SBC drafts left it wide open if a
hch target supports WRITE SAME with UNMAP or UNMAP in this case.
Correct.
hch So I think we'd still
On Wed, Jul 16, 2014 at 11:44:18AM -0400, Martin K. Petersen wrote:
There are lots of devices out there that support WRITE SAME(10) or (16)
without the UNMAP bit. And there are devices that support WRITE SAME w/
UNMAP functionality but not regular WRITE SAME.
Oh, we actually have devices that
Christoph == hch@infradead org h...@infradead.org writes:
Christoph Oh, we actually have devices that support WRITE SAME with
Christoph unmap, but not without? That's defintively a little strange.
Yep :(
There were several SSDs that did not want to support wearing out flash
by writing gobs of
On Wed, Jul 16, 2014 at 01:47:35PM -0400, Martin K. Petersen wrote:
There were several SSDs that did not want to support wearing out flash
by writing gobs of zeroes and only support the UNMAP case.
Given that SSDs usually aren't hard provisioned anyway that seems like
an odd decision. But SAS
On Wed, 2014-07-16 at 13:47 -0400, Martin K. Petersen wrote:
Christoph == hch@infradead org h...@infradead.org writes:
Christoph Oh, we actually have devices that support WRITE SAME with
Christoph unmap, but not without? That's defintively a little strange.
Yep :(
There were several
...@linuxdriverproject.org; a...@canonical.com; k...@microsoft.com;
sta...@vger.kernel.org; linux-s...@vger.kernel.org; oher...@suse.com;
jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-16 at 13:47 -0400, Martin K. Petersen wrote:
Christoph == hch@infradead
James == James Bottomley jbottom...@parallels.com writes:
I don't have a problem with a BLIST_PREFER_UNMAP flag or something
like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
does fix the problem at hand. That's why I went that route.
James Hang on ... unless we apply
On Wed, 2014-07-16 at 14:45 -0400, Martin K. Petersen wrote:
James == James Bottomley jbottom...@parallels.com writes:
I don't have a problem with a BLIST_PREFER_UNMAP flag or something
like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
does fix the problem at hand.
James == James Bottomley jbottom...@parallels.com writes:
James It's the code we identified in sd.c:read_capacity_16():
That's there to support devices that implement thin provisioning but
which predate the LBP VPD page. And thus have no way to tell us their
preferred command variant.
James If
On Wed, 2014-07-16 at 15:08 -0400, Martin K. Petersen wrote:
James == James Bottomley jbottom...@parallels.com writes:
James It's the code we identified in sd.c:read_capacity_16():
That's there to support devices that implement thin provisioning but
which predate the LBP VPD page. And
Rob == Elliott, Robert (Server Storage) elli...@hp.com writes:
Rob WRITE SAME with the UNMAP bit set to one (and a few other
Rob conditions) guarantees that the data is zeroed out, while the UNMAP
Rob command is just a hint. They're not fully interchangeable. Which
Rob semantics are implied by
James == James Bottomley jbottom...@parallels.com writes:
James Well, your judgement: is this situation (support for UNMAP but
James not for WRITE_SAME) in what is effectively a RAID driver (hv
James drivers count as RAID) just a silly Microsoft one off?
I only recall seeing one or two devices
@redhat.com; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; oher...@suse.com;
> h...@infradead.org; James Bottomley; a...@canonical.com;
> de...@linuxdriverproject.org
> Subject: RE: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
>
>
> > -
-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: RE: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
>
>
> > -Original Message-
> > From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> > Sent: Sunday, Ju
canonical.com; sta...@vger.kernel.org;
> linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> >>>>> "KY" == KY Srinivasan writes:
>
> KY> Windows hosts do support UNMAP and set the
> "KY" == KY Srinivasan writes:
KY> Windows hosts do support UNMAP and set the field in the
KY> EVPD. However, since the host advertises SPC-2 compliance, Linux
KY> does not even query the VPD page.
>> If we want to enable UNMAP in this case I'd prefer a blacklist entry
>> than trying
KY == KY Srinivasan k...@microsoft.com writes:
KY Windows hosts do support UNMAP and set the field in the
KY EVPD. However, since the host advertises SPC-2 compliance, Linux
KY does not even query the VPD page.
If we want to enable UNMAP in this case I'd prefer a blacklist entry
than trying
;
linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
KY == KY Srinivasan k...@microsoft.com writes:
KY Windows hosts do support UNMAP and set the field in the EVPD.
KY However, since the host advertises SPC-2
...@suse.com; jasow...@redhat.com
Subject: RE: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Sunday, July 13, 2014 5:59 AM
To: KY Srinivasan
Cc: h...@infradead.org; James Bottomley
...@vger.kernel.org; sta...@vger.kernel.org; oher...@suse.com;
h...@infradead.org; James Bottomley; a...@canonical.com;
de...@linuxdriverproject.org
Subject: RE: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
-Original Message-
From: KY Srinivasan
Sent: Sunday, July 13
canonical.com; sta...@vger.kernel.org;
> linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> >>>>> "hch" == hch@infradead org writes:
>
> (Back from vacation: Bear with me while I'
nonical.com;
> sta...@vger.kernel.org; linux-s...@vger.kernel.org; oher...@suse.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
> > If we fix it at source, why wou
> "hch" == hch@infradead org writes:
(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)
hch> I think the problem is a differnet one. If we have the logical
hch> provisioning EVPD it configures what method to use, but if we don't
hch> have one we
On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
> If we fix it at source, why would there be any need to filter? That's
> the reason the no_write_same flag was introduced. If we can find and
> fix the bug, it can go back into the stable trees as a bug fix, hence
> nothing should
On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
If we fix it at source, why would there be any need to filter? That's
the reason the no_write_same flag was introduced. If we can find and
fix the bug, it can go back into the stable trees as a bug fix, hence
nothing should
hch == hch@infradead org h...@infradead.org writes:
(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)
hch I think the problem is a differnet one. If we have the logical
hch provisioning EVPD it configures what method to use, but if we don't
hch have
...@vger.kernel.org; linux-s...@vger.kernel.org; oher...@suse.com;
jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
If we fix it at source, why would there be any need to filter? That's
the reason
;
linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
hch == hch@infradead org h...@infradead.org writes:
(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)
hch I
p.net; h...@infradead.org;
> > de...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org;
> > linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> > Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
> >
&
..@vger.kernel.org;
> linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, 2014-07-09 at 21:14 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > >
On Wed, Jul 09, 2014 at 10:36:26PM +, KY Srinivasan wrote:
> Ok; I am concerned about older kernels that do not have no_write_same flag.
> I suppose I can work directly with these Distros and give them a choice:
> either implement
> the no_write_same flag or filter the command in our driver.
On Wed, Jul 09, 2014 at 10:36:26PM +, KY Srinivasan wrote:
Ok; I am concerned about older kernels that do not have no_write_same flag.
I suppose I can work directly with these Distros and give them a choice:
either implement
the no_write_same flag or filter the command in our driver. I
...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-09 at 21:14 +, KY Srinivasan wrote:
-Original Message-
From: James Bottomley [mailto:jbottom...@parallels.com]
Sent: Wednesday
...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org;
linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-09 at 21:14 +, KY Srinivasan wrote:
-Original Message-
From
..@vger.kernel.org;
> linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, 2014-07-09 at 21:14 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > >
l.org; h...@infradead.org;
> > de...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org;
> > linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> > Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
> >
> > On Wed, 2014-07-09 at 19:52
nel.org;
> linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, 2014-07-09 at 19:52 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: Ch
project.org;
> > oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com;
> > a...@canonical.com; linux-s...@vger.kernel.org; sta...@vger.kernel.org
> > Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
> >
> > On Tue, Jul 08, 2014 at 05:46
t; a...@canonical.com; linux-s...@vger.kernel.org; sta...@vger.kernel.org
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote:
> > Host does not handle WRITE_SAME_16; filter this command out.
On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote:
> Host does not handle WRITE_SAME_16; filter this command out. This patch
> is required to handle large devices (greater than 2 TB disks).
Storvsc already sets the no_write_same flag, where is the command coming
from?
--
To
On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote:
Host does not handle WRITE_SAME_16; filter this command out. This patch
is required to handle large devices (greater than 2 TB disks).
Storvsc already sets the no_write_same flag, where is the command coming
from?
--
To
-s...@vger.kernel.org; sta...@vger.kernel.org
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote:
Host does not handle WRITE_SAME_16; filter this command out. This
patch is required to handle large devices
...@parallels.com; jasow...@redhat.com;
a...@canonical.com; linux-s...@vger.kernel.org; sta...@vger.kernel.org
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Tue, Jul 08, 2014 at 05:46:48PM -0700, K. Y. Srinivasan wrote:
Host does not handle WRITE_SAME_16; filter
...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-09 at 19:52 +, KY Srinivasan wrote:
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Wednesday, July 9, 2014 1:43
; a...@canonical.com; sta...@vger.kernel.org;
linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-09 at 19:52 +, KY Srinivasan wrote:
-Original Message-
From: Christoph
...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
On Wed, 2014-07-09 at 21:14 +, KY Srinivasan wrote:
-Original Message-
From: James Bottomley [mailto:jbottom...@parallels.com]
Sent: Wednesday
Host does not handle WRITE_SAME_16; filter this command out. This patch
is required to handle large devices (greater than 2 TB disks).
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
Host does not handle WRITE_SAME_16; filter this command out. This patch
is required to handle large devices (greater than 2 TB disks).
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |1 +
1 files changed, 1 insertions(+), 0
68 matches
Mail list logo
