Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 3 Sep 2014, James Bottomley wrote:
> On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
> > On Wed, 3 Sep 2014, James Bottomley wrote:
> >
> > > Before we embark on elaborate hacks, why don't we just make the capacity
> > > writeable (by root) in sysfs from userspace (will require block change)?
> > > We can then encode all the nasty heuristics (including gpt reading) in
> > > userspace as a udev rule.
> >
> > That's what I'm working on. Except that I don't know where to do it in
> > the block layer, so for now I'm adding the attribute to sd.c.
> >
> > Where in the block layer would the right place be? We want this to
> > apply only to entire devices, not to individual partitions.
>
> The bottom layer for this is part0.nr_sects which is the size attribute
> you see in the block sysfs. However, it looks like we keep a separate
> value in sdkp, but we don't ever seem to use it (except to see if the
> capacity has changed).
>
> So this could be done in two ways: add a writeable capacity attribute in
> sd.c, as you were originally thinking (it would call set_capacity() on
> write and that would update the block layer) or make the size parameter
> writeable.
Here's my patch to the sd driver. It seems to work -- writing to the
capacity_override attribute does change the device size. But then you
have to force the kernel to re-read the partition table manually, for
example by running
blockdev --rereadpt /dev/sdX
because I couldn't see any reasonable way to make this happen
automatically.
Alan Stern
Index: usb-3.17/drivers/scsi/sd.h
===
--- usb-3.17.orig/drivers/scsi/sd.h
+++ usb-3.17/drivers/scsi/sd.h
@@ -66,6 +66,7 @@ struct scsi_disk {
struct gendisk *disk;
atomic_topeners;
sector_tcapacity; /* size in 512-byte sectors */
+ sector_tcapacity_override; /* in native-size blocks */
u32 max_xfer_blocks;
u32 max_ws_blocks;
u32 max_unmap_blocks;
Index: usb-3.17/drivers/scsi/sd.c
===
--- usb-3.17.orig/drivers/scsi/sd.c
+++ usb-3.17/drivers/scsi/sd.c
@@ -477,6 +477,38 @@ 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;
+ revalidate_disk(sdkp->disk);
+
+ 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 +521,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);
@@ -2158,6 +2191,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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: James Bottomley > Before we embark on elaborate hacks, why don't we just make the capacity > writeable (by root) in sysfs from userspace (will require block change)? > We can then encode all the nasty heuristics (including gpt reading) in > userspace as a udev rule. Looking in from the outside, this makes sense to me. All the nasty hueristics can be put in userspace -- perhaps as even a special-purpose program, where we can directly warn the user as to what he's getting himself into. (I do not demand that this all work automatically.) And the hueristics can be improved easily, without kernel changes. The only gotcha that I see is that once the recorded device size is changed, the kernel may now consider the partition table to be valid, and should now parse it and set up the special device numbers for the partitions. So that needs to get triggered properly. I suppose there is some complexity if the block-handling layer already has blocks cached and the device size is reduced below the addresses of the cached blocks. But as long as the kernel doesn't crash or write blocks in incorrect places, I don't see that as a problem -- if you set the device size as less than the block numbers you've already written to, that's your problem. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
> On Wed, 3 Sep 2014, James Bottomley wrote:
>
> > Before we embark on elaborate hacks, why don't we just make the capacity
> > writeable (by root) in sysfs from userspace (will require block change)?
> > We can then encode all the nasty heuristics (including gpt reading) in
> > userspace as a udev rule.
>
> That's what I'm working on. Except that I don't know where to do it in
> the block layer, so for now I'm adding the attribute to sd.c.
>
> Where in the block layer would the right place be? We want this to
> apply only to entire devices, not to individual partitions.
The bottom layer for this is part0.nr_sects which is the size attribute
you see in the block sysfs. However, it looks like we keep a separate
value in sdkp, but we don't ever seem to use it (except to see if the
capacity has changed).
So this could be done in two ways: add a writeable capacity attribute in
sd.c, as you were originally thinking (it would call set_capacity() on
write and that would update the block layer) or make the size parameter
writeable.
This is how you would do the block layer one below, but there's no way
to inform the lower layer (so it better not have any information cached
that it makes use of).
James
---
diff --git a/block/genhd.c b/block/genhd.c
index 791f419..a114636 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -980,7 +980,7 @@ static DEVICE_ATTR(range, S_IRUGO, disk_range_show, NULL);
static DEVICE_ATTR(ext_range, S_IRUGO, disk_ext_range_show, NULL);
static DEVICE_ATTR(removable, S_IRUGO, disk_removable_show, NULL);
static DEVICE_ATTR(ro, S_IRUGO, disk_ro_show, NULL);
-static DEVICE_ATTR(size, S_IRUGO, part_size_show, NULL);
+static DEVICE_ATTR(size, S_IRUGO|S_IWUSR, part_size_show, part_size_store);
static DEVICE_ATTR(alignment_offset, S_IRUGO, disk_alignment_offset_show,
NULL);
static DEVICE_ATTR(discard_alignment, S_IRUGO, disk_discard_alignment_show,
NULL);
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 789cdea..d0cc418 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -87,6 +87,20 @@ ssize_t part_size_show(struct device *dev,
return sprintf(buf, "%llu\n",(unsigned long long)part_nr_sects_read(p));
}
+ssize_t part_size_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hd_struct *p = dev_to_part(dev);
+ u64 size;
+
+ if (count > 0 && sscanf(buf, "%llu", &size) > 0)
+ part_nr_sects_write(p, size);
+ else
+ return -EINVAL;
+
+ return count;
+}
+
static ssize_t part_ro_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index ec274e0..c9b3473 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -628,6 +628,9 @@ extern void blk_unregister_region(dev_t devt, unsigned long
range);
extern ssize_t part_size_show(struct device *dev,
struct device_attribute *attr, char *buf);
+extern ssize_t part_size_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
extern ssize_t part_stat_show(struct device *dev,
struct device_attribute *attr, char *buf);
extern ssize_t part_inflight_show(struct device *dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 3 Sep 2014, James Bottomley wrote: > Before we embark on elaborate hacks, why don't we just make the capacity > writeable (by root) in sysfs from userspace (will require block change)? > We can then encode all the nasty heuristics (including gpt reading) in > userspace as a udev rule. That's what I'm working on. Except that I don't know where to do it in the block layer, so for now I'm adding the attribute to sd.c. Where in the block layer would the right place be? We want this to apply only to entire devices, not to individual partitions. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 2014-09-03 at 15:05 -0400, Alan Stern wrote: > On Wed, 3 Sep 2014, Dale R. Worley wrote: > > > > From: Alan Stern > > > > > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > > > Is there an 'easy' way to override the detected size of a storage > > > > device from userspace? If we had that, someone could write a helper > > > > application which looked for this particular fubar and try to Do The > > > > Right Thing(tm), or at least offer the user some options. > > > > > > You mean, force a Media Change event and override the capacity reported > > > by the hardware? I'm not aware of any API for doing that, although it > > > probably wouldn't be too hard to add one. > > > > > > How would the user know what value to put in for the capacity? Unless > > > the drive had been hooked up to a different computer and the user > > > manually noted the correct capacity and typed it in, it would have to > > > be guesswork. > > > > The value would most sanely be extracted from the partition table. > > (After verifying that the partition table looks correct.) That seems > > to be what Windows does, and it seems to work consistently enough for > > Windows to trust that method. Or at least, it could take the disk > > size to be the end of the last partition, which would at least make > > all the partitions accessible. > > If there is a partition table. It might be worthwhile to try an ATA > pass-through command as well. > > > As somebody else hinted at, the userspace program could check the USB > > device against a list of device types known to have this problem. > > > > It could even verify that the SCSI-reported size matches the size > > reported by the partition table (modulo two-to-the-whatever) (at least > > for GPT tables, I don't know if MBR tables report the disk size). > > They don't. Just the start and end of each partition. > > > Do we have any way of knowing what algorithm Windows uses in this > > situation? > > Ask Microsoft. I suspect you're not likely to get an answer, though. > > Anyway, I can try writing a patch to add this capability. We'll see if > it can solve your problem. Before we embark on elaborate hacks, why don't we just make the capacity writeable (by root) in sysfs from userspace (will require block change)? We can then encode all the nasty heuristics (including gpt reading) in userspace as a udev rule. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > Anyway, I can try writing a patch to add this capability. We'll see if > it can solve your problem. Unfortunately, I think there is genuine value in such a hack. E.g., I've got two USB-to-SATA adapters. One works correctly. One does not. But at this point, I can't attach both of my high-capacity disks to the laptop at the same time, which makes it difficult to bulk-transfer files from one to the other. If, for the deficient adapter, the kernel assumed the disk size was the end of the last partition (or the backup GPT partition table, if that follows), then I could use it for everything other than repartitioning. And that would make life easier. Thanks for trying, Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RES: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, 30 Aug 2014, Matthew Dharm wrote > I was thinking of something that could notice a USB device which is formatted > NTFS and has a partition table and filesystem that indicates a much bigger > capacity than what the drive reports. Under this circumstances, you could do > something like pop-up a dialog box saying "this drive is confused -- is it > 2TB or > 3TB?" > > Well, maybe that would say "Drive capacity is not consistent with partition > table. This can happen with certain USB drives designed for use with > Windows. Override drive capacity (emulating Windows)?" > > You could imagine increasing complex heuristics to try to detect this > scenario. > Even without an automated helper program to do it, if there was a sysfs > interface then when we got the periodic e-mails reporting this same type of > problem, we could offer a quick-and-clean solution. Hi Matt, I did small hack to skip is_pte_valid() on efi.c and now I have sdc1 partition listed on /proc/partition, but I hit other issue: ntfs-3g mount userspace tool that comes with Fedora now fails with "Failed to read last sector (7814037100): Invalid argument". I also tried to override disk capacity, but SD driver fails with "Invalid command failure" and "Illegal Request" (I'll investigate it later) Many places rely on disk capacity value, I think emulate Windows behavior for these HDD docks will not be an easy task []'s Alfredo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 3 Sep 2014, Dale R. Worley wrote: > > From: Alan Stern > > > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > > Is there an 'easy' way to override the detected size of a storage > > > device from userspace? If we had that, someone could write a helper > > > application which looked for this particular fubar and try to Do The > > > Right Thing(tm), or at least offer the user some options. > > > > You mean, force a Media Change event and override the capacity reported > > by the hardware? I'm not aware of any API for doing that, although it > > probably wouldn't be too hard to add one. > > > > How would the user know what value to put in for the capacity? Unless > > the drive had been hooked up to a different computer and the user > > manually noted the correct capacity and typed it in, it would have to > > be guesswork. > > The value would most sanely be extracted from the partition table. > (After verifying that the partition table looks correct.) That seems > to be what Windows does, and it seems to work consistently enough for > Windows to trust that method. Or at least, it could take the disk > size to be the end of the last partition, which would at least make > all the partitions accessible. If there is a partition table. It might be worthwhile to try an ATA pass-through command as well. > As somebody else hinted at, the userspace program could check the USB > device against a list of device types known to have this problem. > > It could even verify that the SCSI-reported size matches the size > reported by the partition table (modulo two-to-the-whatever) (at least > for GPT tables, I don't know if MBR tables report the disk size). They don't. Just the start and end of each partition. > Do we have any way of knowing what algorithm Windows uses in this > situation? Ask Microsoft. I suspect you're not likely to get an answer, though. Anyway, I can try writing a patch to add this capability. We'll see if it can solve your problem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > Is there an 'easy' way to override the detected size of a storage > > device from userspace? If we had that, someone could write a helper > > application which looked for this particular fubar and try to Do The > > Right Thing(tm), or at least offer the user some options. > > You mean, force a Media Change event and override the capacity reported > by the hardware? I'm not aware of any API for doing that, although it > probably wouldn't be too hard to add one. > > How would the user know what value to put in for the capacity? Unless > the drive had been hooked up to a different computer and the user > manually noted the correct capacity and typed it in, it would have to > be guesswork. The value would most sanely be extracted from the partition table. (After verifying that the partition table looks correct.) That seems to be what Windows does, and it seems to work consistently enough for Windows to trust that method. Or at least, it could take the disk size to be the end of the last partition, which would at least make all the partitions accessible. As somebody else hinted at, the userspace program could check the USB device against a list of device types known to have this problem. It could even verify that the SCSI-reported size matches the size reported by the partition table (modulo two-to-the-whatever) (at least for GPT tables, I don't know if MBR tables report the disk size). Do we have any way of knowing what algorithm Windows uses in this situation? Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, 30 Aug 2014, Douglas Gilbert wrote: > On 14-08-30 05:15 PM, Alan Stern wrote: > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > > >> Is there an 'easy' way to override the detected size of a storage > >> device from userspace? If we had that, someone could write a helper > >> application which looked for this particular fubar and try to Do The > >> Right Thing(tm), or at least offer the user some options. > > > > You mean, force a Media Change event and override the capacity reported > > by the hardware? I'm not aware of any API for doing that, although it > > probably wouldn't be too hard to add one. > > > > How would the user know what value to put in for the capacity? Unless > > the drive had been hooked up to a different computer and the user > > manually noted the correct capacity and typed it in, it would have to > > be guesswork. > > Might another possibility be using the SAT layer to issue > the appropriate ATA command via the SCSI ATA PASS-THROUGH > (12 or 16) command to find out the disk's size. That might work. Not all USB mass-storage devices support ATA pass-through but some of them do. > This might > be a possible strategy if READ CAPACITY(10) yields 0x > for the last sector's LBA and the follow-up READ CAPACITY(16) > fails or yields a truncated value. Yes. The problem in this case is that READ CAPACITY(10) yields a reasonable value (not 0x), so READ CAPACITY(16) never gets sent. And if it was sent, the device wouldn't handle it anyway. > BTW Been looking at a USB-to-SATA adapter that uses the > UAS(P) transport. I thought nothing could have worse > SCSI compliance than USB mass storage devices. I was > wrong ... Well, a USB-to-SATA adapter _is_ a USB mass-storage device. What vendor and product? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, Aug 30, 2014 at 2:15 PM, Alan Stern wrote: > On Fri, 29 Aug 2014, Matthew Dharm wrote: > >> Is there an 'easy' way to override the detected size of a storage >> device from userspace? If we had that, someone could write a helper >> application which looked for this particular fubar and try to Do The >> Right Thing(tm), or at least offer the user some options. > > You mean, force a Media Change event and override the capacity reported > by the hardware? I'm not aware of any API for doing that, although it > probably wouldn't be too hard to add one. > > How would the user know what value to put in for the capacity? Unless > the drive had been hooked up to a different computer and the user > manually noted the correct capacity and typed it in, it would have to > be guesswork. I didn't say it would be easy to figure out the right value, but at least it would be possible. I was thinking of something that could notice a USB device which is formatted NTFS and has a partition table and filesystem that indicates a much bigger capacity than what the drive reports. Under this circumstances, you could do something like pop-up a dialog box saying "this drive is confused -- is it 2TB or 3TB?" Well, maybe that would say "Drive capacity is not consistent with partition table. This can happen with certain USB drives designed for use with Windows. Override drive capacity (emulating Windows)?" You could imagine increasing complex heuristics to try to detect this scenario. Even without an automated helper program to do it, if there was a sysfs interface then when we got the periodic e-mails reporting this same type of problem, we could offer a quick-and-clean solution. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On 14-08-30 05:15 PM, Alan Stern wrote: On Fri, 29 Aug 2014, Matthew Dharm wrote: Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. Might another possibility be using the SAT layer to issue the appropriate ATA command via the SCSI ATA PASS-THROUGH (12 or 16) command to find out the disk's size. This might be a possible strategy if READ CAPACITY(10) yields 0x for the last sector's LBA and the follow-up READ CAPACITY(16) fails or yields a truncated value. Doug Gilbert BTW Been looking at a USB-to-SATA adapter that uses the UAS(P) transport. I thought nothing could have worse SCSI compliance than USB mass storage devices. I was wrong ... -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Fri, 29 Aug 2014, Matthew Dharm wrote: > Is there an 'easy' way to override the detected size of a storage > device from userspace? If we had that, someone could write a helper > application which looked for this particular fubar and try to Do The > Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. Matt On Fri, Aug 29, 2014 at 2:07 PM, Dale R. Worley wrote: >> From: Alan Stern > >> If you try to repartition the drive under Windows using the deficient >> adapter, you'll see that the problem still exists. It just doesn't >> show up during normal use. > > So in summary, the Windows workaround is icky, but it allows any use > but repartitioning to be one on the attached disk. > > Dale > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > If you try to repartition the drive under Windows using the deficient > adapter, you'll see that the problem still exists. It just doesn't > show up during normal use. So in summary, the Windows workaround is icky, but it allows any use but repartitioning to be one on the attached disk. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 27 Aug 2014, Dale R. Worley wrote: > What I find interesting is that Windows (at least, Windows 7 > Professional) seems to be able to handle the deficient adapter. So does Linux. The difference is that Windows believes the values in the partition table in preference to what the hardware says, whereas Linux believes the hardware in preference to the partition table. Thus, if the hardware says the disk contains 0.8 TB and the partition table says the first partition contains 2.8 TB, Windows will try to access all 2.8 TB but Linux will complain that the partition entry is invalid (because the partition extends beyond the end of the disk). If you try to repartition the drive under Windows using the deficient adapter, you'll see that the problem still exists. It just doesn't show up during normal use. > What > I'd like to do is log the disk commands during the mounting sequence, > preferably at both the SCSI and USB layers. Then at least we'll know > exactly what the driver is doing. Are there kernel options to do > this? You can record the USB transfers by using usbmon (see Documentation/usb/usbmon.txt). The trace will include all the important SCSI data, so you don't need to record anything at the SCSI layer. This isn't really necessary, though. We already know what the driver is doing. > Unfortunately, I don't know any way to log what Windows is doing with > the drive. My experiments with Windows show that it does essentially the same things as Linux does. The important difference is not what commands and data get sent, but whether the OS pays attention to the result. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 2014-08-27 at 15:21 -0400, Dale R. Worley wrote: > > From: James Bottomley > > > Did you try read capacity 16 on it? What happened? (the AS2105 rejects > > read capacity 16, so there's no reliable way to deduce the capacity of > > drives over 2TB). > > OK, I had to track down which package contains sg_readcap. > > The adapter that fails gives this output: > > # sg_readcap --16 /dev/sdb > bad field in READ CAPACITY (16) cdb including unsupported service action OK, so that's definitely the tame taxonomy. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
What I find interesting is that Windows (at least, Windows 7 Professional) seems to be able to handle the deficient adapter. What I'd like to do is log the disk commands during the mounting sequence, preferably at both the SCSI and USB layers. Then at least we'll know exactly what the driver is doing. Are there kernel options to do this? Unfortunately, I don't know any way to log what Windows is doing with the drive. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: James Bottomley > Did you try read capacity 16 on it? What happened? (the AS2105 rejects > read capacity 16, so there's no reliable way to deduce the capacity of > drives over 2TB). OK, I had to track down which package contains sg_readcap. The adapter that fails gives this output: # sg_readcap --16 /dev/sdb bad field in READ CAPACITY (16) cdb including unsupported service action The adapter that succeeds gives this output: # sg_readcap --16 /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=5860533167 (0x15d50a3af), Number of logical blocks=5860533168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Tue, 2014-08-26 at 15:39 -0400, Dale R. Worley wrote: > This is almost certainly a form of the problem reported in > "AS2105-based enclosure size issues with >2TB HDDs". I'm repeating my > original message here so linux-usb can see it, and so it can be > connected to the older thread. I'll address it in another message. Did you try read capacity 16 on it? What happened? (the AS2105 rejects read capacity 16, so there's no reliable way to deduce the capacity of drives over 2TB). James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
This is almost certainly a form of the problem reported in "AS2105-based enclosure size issues with >2TB HDDs". I'm repeating my original message here so linux-usb can see it, and so it can be connected to the older thread. I'll address it in another message. I've appended James Bottomley's response, to avoid creating an additional message. Dale -- Date: Wed, 20 Aug 2014 16:18:00 -0400 From: wor...@alum.mit.edu (Dale R. Worley) To: linux-scsi@vger.kernel.org Subject: Problem with USB-to-SATA adapters I don't know if this is the correct place for this problem, but you people can probably tell me the correct place. I have two "USB to SATA adapter" dongles. In general, they work fine. However I've discovered that one of them handles large (1 TB and above) drives correctly and one does not. In particular, when I use the unsuccessful one, neither fdisk nor gdisk reports the disk size correctly, and the kernel does not read the partition table. More confusingly, both dongles work correctly with large disks on Windows 7 Professional. Both of the following cases are when a 3.0 TB drive is attached. The successful device has the "Diablo" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) The unsuccessful device has the "Ez-Connect" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:54:06 hobgoblin kernel: [ 127.674374] usb 2-2: new high-speed USB device number 4 using ehci-pci Aug 18 21:54:06 hobgoblin kernel: [ 127.791128] usb 2-2: New USB device found, idVendor=05e3, idProduct=0718 Aug 18 21:54:06 hobgoblin kernel: [ 127.791135] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=2 Aug 18 21:54:06 hobgoblin kernel: [ 127.791138] usb 2-2: Product: USB Storage Aug 18 21:54:06 hobgoblin kernel: [ 127.791142] usb 2-2: SerialNumber: 0033 Aug 18 21:54:07 hobgoblin kernel: [ 128.847269] sd 6:0:0:0: [sdb] 1565565872 512-byte logical blocks: (801 GB/746 GiB) Dale -- For the Diablo adapter: Aug 18 21:56:53 hobgoblin kernel: [ 294.153343] usb 2-1.3: new high-speed USB device number 5 using ehci-pci Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:53 hobgoblin kernel: [ 294.231159] usb-storage 2-1.3:1.0: USB Mass Storage device detected Aug 18 21:56:53 hobgoblin kernel: [ 294.233951] scsi7 : usb-storage 2-1.3:1.0 Aug 18 21:56:53 hobgoblin mtp-probe: checking bus 2, device 5: "/sys/devices/pci:00/:00:1d.7/usb2/2-1/2-1.3" Aug 18 21:56:53 hobgoblin mtp-probe: bus: 2, device: 5 was not an MTP device Aug 18 21:56:54 hobgoblin kernel: [ 295.235735] scsi 7:0:0:0: Direct-Access WDC WD30 EZRX-00SPEB0 PQ: 0 ANSI: 5 Aug 18 21:56:54 hobgoblin kernel: [ 295.236209] sd 7:0:0:0: Attached scsi generic sg2 type 0 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Aug 18 21:56:54 hobgoblin kernel: [ 295.237957] sd 7:0:0:0: [sdb] Write Protect is off Aug 18 21:56:54 hobgoblin kernel: [ 295.238957] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [ 295.238962] sd 7:0:0:0: [sdb] Assuming drive cache: write through Aug 18 21:56:54 hobgoblin kernel: [ 295.239956] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.242334] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [ 295.242339] sd 7:0:0:0: [sdb] Assuming drive cache: write through Aug 18 21:56:54 hobgob
