* [PATCH] scsi: sd: add a capacity_override attribute
@ 2015-03-17 18:08 Alan Stern
2015-03-20 14:40 ` Ewan Milne
0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2015-03-17 18:08 UTC (permalink / raw)
To: James Bottomley; +Cc: SCSI development list
This patch provides a sysfs interface allowing users to override the
capacity of a SCSI disk. This will help in situations where a buggy
USB-SATA adapter fails to support READ CAPACITY(16) and reports only
the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
an example, see this thread:
http://marc.info/?l=linux-scsi&m=140908235510961&w=2
The interface is awkward because it requires the user to tell the
system to re-read the disk's partition table afterward, but at least
it provides a way to handle deficient hardware.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Dale R. Worley <worley@alum.mit.edu>
---
[as1777]
Documentation/ABI/testing/sysfs-class-scsi_disk | 19 ++++++++++++
drivers/scsi/sd.c | 37 ++++++++++++++++++++++++
drivers/scsi/sd.h | 1
3 files changed, 57 insertions(+)
Index: usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
===================================================================
--- /dev/null
+++ usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
@@ -0,0 +1,19 @@
+What: /sys/class/scsi_disk/HOST:CHANNEL:TARGET:LUN/capacity_override
+Date: March 2015
+KernelVersion: 4.1
+Contact: Alan Stern <stern@rowland.harvard.edu>
+Description:
+ This file provides a way for users to override the
+ automatically determined disk capacity. For example, some
+ buggy USB-SATA adapters report only the low 32 bits of a
+ drive's block count, resulting in a calculated capacity
+ value that is the actual capacity modulo 2 TB.
+
+ After the correct capacity (in native-size blocks -- often
+ 512 bytes per block but sometimes 4096) is written to this
+ file, the user must tell the system to re-read the disk's
+ partition table by running the command:
+
+ /usr/sbin/blockdev --rereadpt /dev/sdX
+
+ where X is the disk's drive letter.
Index: usb-4.0/drivers/scsi/sd.h
===================================================================
--- usb-4.0.orig/drivers/scsi/sd.h
+++ usb-4.0/drivers/scsi/sd.h
@@ -66,6 +66,7 @@ struct scsi_disk {
struct gendisk *disk;
atomic_t openers;
sector_t capacity; /* size in 512-byte sectors */
+ sector_t capacity_override; /* in native-size blocks */
u32 max_xfer_blocks;
u32 max_ws_blocks;
u32 max_unmap_blocks;
Index: usb-4.0/drivers/scsi/sd.c
===================================================================
--- usb-4.0.orig/drivers/scsi/sd.c
+++ usb-4.0/drivers/scsi/sd.c
@@ -477,6 +477,35 @@ max_write_same_blocks_store(struct devic
}
static DEVICE_ATTR_RW(max_write_same_blocks);
+static ssize_t
+capacity_override_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+
+ return sprintf(buf, "%llu\n",
+ (unsigned long long) sdkp->capacity_override);
+}
+
+static ssize_t
+capacity_override_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+ unsigned long long cap;
+ int err;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+ err = kstrtoull(buf, 10, &cap);
+ if (err)
+ return err;
+ sdkp->capacity_override = cap;
+ return count;
+}
+static DEVICE_ATTR_RW(capacity_override);
+
static struct attribute *sd_disk_attrs[] = {
&dev_attr_cache_type.attr,
&dev_attr_FUA.attr,
@@ -489,6 +518,7 @@ static struct attribute *sd_disk_attrs[]
&dev_attr_provisioning_mode.attr,
&dev_attr_max_write_same_blocks.attr,
&dev_attr_max_medium_access_timeouts.attr,
+ &dev_attr_capacity_override.attr,
NULL,
};
ATTRIBUTE_GROUPS(sd_disk);
@@ -2152,6 +2182,13 @@ sd_read_capacity(struct scsi_disk *sdkp,
struct scsi_device *sdp = sdkp->device;
sector_t old_capacity = sdkp->capacity;
+ /* Did the user override the reported capacity? */
+ if (!sdkp->first_scan && sdkp->capacity_override) {
+ sector_size = sdkp->device->sector_size;
+ sdkp->capacity = sdkp->capacity_override;
+ goto got_data;
+ }
+
if (sd_try_rc16_first(sdp)) {
sector_size = read_capacity_16(sdkp, sdp, buffer);
if (sector_size == -EOVERFLOW)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] scsi: sd: add a capacity_override attribute
2015-03-17 18:08 [PATCH] scsi: sd: add a capacity_override attribute Alan Stern
@ 2015-03-20 14:40 ` Ewan Milne
2015-03-20 15:19 ` Alan Stern
0 siblings, 1 reply; 6+ messages in thread
From: Ewan Milne @ 2015-03-20 14:40 UTC (permalink / raw)
To: Alan Stern; +Cc: James Bottomley, SCSI development list
On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> This patch provides a sysfs interface allowing users to override the
> capacity of a SCSI disk. This will help in situations where a buggy
> USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
> an example, see this thread:
>
> http://marc.info/?l=linux-scsi&m=140908235510961&w=2
>
> The interface is awkward because it requires the user to tell the
> system to re-read the disk's partition table afterward, but at least
> it provides a way to handle deficient hardware.
I think that it is confusing that writing into the capacity_override
sysfs node does not get immediately reflected in the gendisk structure.
Would it hurt to call sd_revalidate_disk() after the value is changed
in capacity_override_store()?
The thing is, if someone overrides the capacity but does not do anything
right away to revalidate the disk, it could change at some arbitrary
time in the future when the revalidation happens for some other reason.
-Ewan
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: Dale R. Worley <worley@alum.mit.edu>
>
> ---
>
>
> [as1777]
>
>
> Documentation/ABI/testing/sysfs-class-scsi_disk | 19 ++++++++++++
> drivers/scsi/sd.c | 37 ++++++++++++++++++++++++
> drivers/scsi/sd.h | 1
> 3 files changed, 57 insertions(+)
>
> Index: usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
> ===================================================================
> --- /dev/null
> +++ usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
> @@ -0,0 +1,19 @@
> +What: /sys/class/scsi_disk/HOST:CHANNEL:TARGET:LUN/capacity_override
> +Date: March 2015
> +KernelVersion: 4.1
> +Contact: Alan Stern <stern@rowland.harvard.edu>
> +Description:
> + This file provides a way for users to override the
> + automatically determined disk capacity. For example, some
> + buggy USB-SATA adapters report only the low 32 bits of a
> + drive's block count, resulting in a calculated capacity
> + value that is the actual capacity modulo 2 TB.
> +
> + After the correct capacity (in native-size blocks -- often
> + 512 bytes per block but sometimes 4096) is written to this
> + file, the user must tell the system to re-read the disk's
> + partition table by running the command:
> +
> + /usr/sbin/blockdev --rereadpt /dev/sdX
> +
> + where X is the disk's drive letter.
> Index: usb-4.0/drivers/scsi/sd.h
> ===================================================================
> --- usb-4.0.orig/drivers/scsi/sd.h
> +++ usb-4.0/drivers/scsi/sd.h
> @@ -66,6 +66,7 @@ struct scsi_disk {
> struct gendisk *disk;
> atomic_t openers;
> sector_t capacity; /* size in 512-byte sectors */
> + sector_t capacity_override; /* in native-size blocks */
> u32 max_xfer_blocks;
> u32 max_ws_blocks;
> u32 max_unmap_blocks;
> Index: usb-4.0/drivers/scsi/sd.c
> ===================================================================
> --- usb-4.0.orig/drivers/scsi/sd.c
> +++ usb-4.0/drivers/scsi/sd.c
> @@ -477,6 +477,35 @@ max_write_same_blocks_store(struct devic
> }
> static DEVICE_ATTR_RW(max_write_same_blocks);
>
> +static ssize_t
> +capacity_override_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> +
> + return sprintf(buf, "%llu\n",
> + (unsigned long long) sdkp->capacity_override);
> +}
> +
> +static ssize_t
> +capacity_override_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> + unsigned long long cap;
> + int err;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + err = kstrtoull(buf, 10, &cap);
> + if (err)
> + return err;
> + sdkp->capacity_override = cap;
> + return count;
> +}
> +static DEVICE_ATTR_RW(capacity_override);
> +
> static struct attribute *sd_disk_attrs[] = {
> &dev_attr_cache_type.attr,
> &dev_attr_FUA.attr,
> @@ -489,6 +518,7 @@ static struct attribute *sd_disk_attrs[]
> &dev_attr_provisioning_mode.attr,
> &dev_attr_max_write_same_blocks.attr,
> &dev_attr_max_medium_access_timeouts.attr,
> + &dev_attr_capacity_override.attr,
> NULL,
> };
> ATTRIBUTE_GROUPS(sd_disk);
> @@ -2152,6 +2182,13 @@ sd_read_capacity(struct scsi_disk *sdkp,
> struct scsi_device *sdp = sdkp->device;
> sector_t old_capacity = sdkp->capacity;
>
> + /* Did the user override the reported capacity? */
> + if (!sdkp->first_scan && sdkp->capacity_override) {
> + sector_size = sdkp->device->sector_size;
> + sdkp->capacity = sdkp->capacity_override;
> + goto got_data;
> + }
> +
> if (sd_try_rc16_first(sdp)) {
> sector_size = read_capacity_16(sdkp, sdp, buffer);
> if (sector_size == -EOVERFLOW)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] scsi: sd: add a capacity_override attribute
2015-03-20 14:40 ` Ewan Milne
@ 2015-03-20 15:19 ` Alan Stern
2015-03-20 15:33 ` Ewan Milne
0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2015-03-20 15:19 UTC (permalink / raw)
To: Ewan Milne; +Cc: James Bottomley, SCSI development list
On Fri, 20 Mar 2015, Ewan Milne wrote:
> On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > This patch provides a sysfs interface allowing users to override the
> > capacity of a SCSI disk. This will help in situations where a buggy
> > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
> > an example, see this thread:
> >
> > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> >
> > The interface is awkward because it requires the user to tell the
> > system to re-read the disk's partition table afterward, but at least
> > it provides a way to handle deficient hardware.
>
> I think that it is confusing that writing into the capacity_override
> sysfs node does not get immediately reflected in the gendisk structure.
> Would it hurt to call sd_revalidate_disk() after the value is changed
> in capacity_override_store()?
It wouldn't hurt, but it wouldn't help much either.
sd_revalidate_disk() might cause the new size to show up in the
gendisk structure, but it would not cause the partition table to be
parsed again. That's the real reason for doing this -- when a drive
seems to have fewer blocks than it really does, partitions that extend
beyond the "end" of the drive are rejected.
> The thing is, if someone overrides the capacity but does not do anything
> right away to revalidate the disk, it could change at some arbitrary
> time in the future when the revalidation happens for some other reason.
That's why the documentation says that users must force the system to
re-read the partition table after writing the sysfs attribute. In my
tests, doing that caused a revalidation.
Are you saying that could have been a coincidence? It's possible -- I
don't understand the design of the block layer.
Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] scsi: sd: add a capacity_override attribute
2015-03-20 15:19 ` Alan Stern
@ 2015-03-20 15:33 ` Ewan Milne
2015-03-20 16:03 ` Alan Stern
0 siblings, 1 reply; 6+ messages in thread
From: Ewan Milne @ 2015-03-20 15:33 UTC (permalink / raw)
To: Alan Stern; +Cc: James Bottomley, SCSI development list
On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> On Fri, 20 Mar 2015, Ewan Milne wrote:
>
> > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > This patch provides a sysfs interface allowing users to override the
> > > capacity of a SCSI disk. This will help in situations where a buggy
> > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
> > > an example, see this thread:
> > >
> > > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > >
> > > The interface is awkward because it requires the user to tell the
> > > system to re-read the disk's partition table afterward, but at least
> > > it provides a way to handle deficient hardware.
> >
> > I think that it is confusing that writing into the capacity_override
> > sysfs node does not get immediately reflected in the gendisk structure.
> > Would it hurt to call sd_revalidate_disk() after the value is changed
> > in capacity_override_store()?
>
> It wouldn't hurt, but it wouldn't help much either.
>
> sd_revalidate_disk() might cause the new size to show up in the
> gendisk structure, but it would not cause the partition table to be
> parsed again. That's the real reason for doing this -- when a drive
> seems to have fewer blocks than it really does, partitions that extend
> beyond the "end" of the drive are rejected.
OK, I see.
>
> > The thing is, if someone overrides the capacity but does not do anything
> > right away to revalidate the disk, it could change at some arbitrary
> > time in the future when the revalidation happens for some other reason.
>
> That's why the documentation says that users must force the system to
> re-read the partition table after writing the sysfs attribute. In my
> tests, doing that caused a revalidation.
>
> Are you saying that could have been a coincidence? It's possible -- I
> don't understand the design of the block layer.
No, I think that re-reading the partition table will revalidate. What I
was concerned about is some unsuspecting user writing to the
capacity_override sysfs node, observing that it didn't seem to do
anything, and being surprised when it changed later. (I've seen some
issues with multipath, for example, which will stop using a path if the
capacity changes.) I guess it's a "principle of least surprise" thing.
Having said that, if this is what is needed to make the devices work...
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] scsi: sd: add a capacity_override attribute
2015-03-20 15:33 ` Ewan Milne
@ 2015-03-20 16:03 ` Alan Stern
2015-03-20 16:32 ` Ewan Milne
0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2015-03-20 16:03 UTC (permalink / raw)
To: Ewan Milne; +Cc: James Bottomley, SCSI development list
On Fri, 20 Mar 2015, Ewan Milne wrote:
> On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> > On Fri, 20 Mar 2015, Ewan Milne wrote:
> >
> > > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > > This patch provides a sysfs interface allowing users to override the
> > > > capacity of a SCSI disk. This will help in situations where a buggy
> > > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > > the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
> > > > an example, see this thread:
> > > >
> > > > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > > >
> > > > The interface is awkward because it requires the user to tell the
> > > > system to re-read the disk's partition table afterward, but at least
> > > > it provides a way to handle deficient hardware.
> > >
> > > I think that it is confusing that writing into the capacity_override
> > > sysfs node does not get immediately reflected in the gendisk structure.
> > > Would it hurt to call sd_revalidate_disk() after the value is changed
> > > in capacity_override_store()?
> >
> > It wouldn't hurt, but it wouldn't help much either.
> >
> > sd_revalidate_disk() might cause the new size to show up in the
> > gendisk structure, but it would not cause the partition table to be
> > parsed again. That's the real reason for doing this -- when a drive
> > seems to have fewer blocks than it really does, partitions that extend
> > beyond the "end" of the drive are rejected.
>
> OK, I see.
>
> >
> > > The thing is, if someone overrides the capacity but does not do anything
> > > right away to revalidate the disk, it could change at some arbitrary
> > > time in the future when the revalidation happens for some other reason.
> >
> > That's why the documentation says that users must force the system to
> > re-read the partition table after writing the sysfs attribute. In my
> > tests, doing that caused a revalidation.
> >
> > Are you saying that could have been a coincidence? It's possible -- I
> > don't understand the design of the block layer.
>
> No, I think that re-reading the partition table will revalidate. What I
> was concerned about is some unsuspecting user writing to the
> capacity_override sysfs node, observing that it didn't seem to do
> anything, and being surprised when it changed later. (I've seen some
> issues with multipath, for example, which will stop using a path if the
> capacity changes.) I guess it's a "principle of least surprise" thing.
>
> Having said that, if this is what is needed to make the devices work...
>
> Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Thanks. I don't _mind_ adding an sd_revalidate_disk() call if you
think it will improve the patch. What's your suggestion?
Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] scsi: sd: add a capacity_override attribute
2015-03-20 16:03 ` Alan Stern
@ 2015-03-20 16:32 ` Ewan Milne
0 siblings, 0 replies; 6+ messages in thread
From: Ewan Milne @ 2015-03-20 16:32 UTC (permalink / raw)
To: Alan Stern; +Cc: James Bottomley, SCSI development list
On Fri, 2015-03-20 at 12:03 -0400, Alan Stern wrote:
> On Fri, 20 Mar 2015, Ewan Milne wrote:
>
> > On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> > > On Fri, 20 Mar 2015, Ewan Milne wrote:
> > >
> > > > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > > > This patch provides a sysfs interface allowing users to override the
> > > > > capacity of a SCSI disk. This will help in situations where a buggy
> > > > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > > > the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
> > > > > an example, see this thread:
> > > > >
> > > > > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > > > >
> > > > > The interface is awkward because it requires the user to tell the
> > > > > system to re-read the disk's partition table afterward, but at least
> > > > > it provides a way to handle deficient hardware.
> > > >
> > > > I think that it is confusing that writing into the capacity_override
> > > > sysfs node does not get immediately reflected in the gendisk structure.
> > > > Would it hurt to call sd_revalidate_disk() after the value is changed
> > > > in capacity_override_store()?
> > >
> > > It wouldn't hurt, but it wouldn't help much either.
> > >
> > > sd_revalidate_disk() might cause the new size to show up in the
> > > gendisk structure, but it would not cause the partition table to be
> > > parsed again. That's the real reason for doing this -- when a drive
> > > seems to have fewer blocks than it really does, partitions that extend
> > > beyond the "end" of the drive are rejected.
> >
> > OK, I see.
> >
> > >
> > > > The thing is, if someone overrides the capacity but does not do anything
> > > > right away to revalidate the disk, it could change at some arbitrary
> > > > time in the future when the revalidation happens for some other reason.
> > >
> > > That's why the documentation says that users must force the system to
> > > re-read the partition table after writing the sysfs attribute. In my
> > > tests, doing that caused a revalidation.
> > >
> > > Are you saying that could have been a coincidence? It's possible -- I
> > > don't understand the design of the block layer.
> >
> > No, I think that re-reading the partition table will revalidate. What I
> > was concerned about is some unsuspecting user writing to the
> > capacity_override sysfs node, observing that it didn't seem to do
> > anything, and being surprised when it changed later. (I've seen some
> > issues with multipath, for example, which will stop using a path if the
> > capacity changes.) I guess it's a "principle of least surprise" thing.
> >
> > Having said that, if this is what is needed to make the devices work...
> >
> > Reviewed-by: Ewan D. Milne <emilne@redhat.com>
>
> Thanks. I don't _mind_ adding an sd_revalidate_disk() call if you
> think it will improve the patch. What's your suggestion?
>
If that does not cause the partition table to be updated, then it
doesn't solve your problem, so I'd leave it the way it is, for now.
-Ewan
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-03-20 16:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-17 18:08 [PATCH] scsi: sd: add a capacity_override attribute Alan Stern
2015-03-20 14:40 ` Ewan Milne
2015-03-20 15:19 ` Alan Stern
2015-03-20 15:33 ` Ewan Milne
2015-03-20 16:03 ` Alan Stern
2015-03-20 16:32 ` Ewan Milne
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox