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 james.bottom...@hansenpartnership.com 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)
From: Alan Stern st...@rowland.harvard.edu 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 Wed, 3 Sep 2014, Dale R. Worley wrote: From: Alan Stern st...@rowland.harvard.edu 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 st...@rowland.harvard.edu 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
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 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 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 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)
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 Sat, Aug 30, 2014 at 2:15 PM, Alan Stern st...@rowland.harvard.edu 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)
From: Alan Stern st...@rowland.harvard.edu 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)
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 wor...@alum.mit.edu wrote: From: Alan Stern st...@rowland.harvard.edu 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: James Bottomley james.bottom...@hansenpartnership.com 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)
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)
On Wed, 2014-08-27 at 15:21 -0400, Dale R. Worley wrote: From: James Bottomley james.bottom...@hansenpartnership.com 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)
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 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
