4k sectors and Linux

[Arno]

Seems something is working right. With fdisk (util-linux-ng 2.17.2)
and kernel 2.6.38.8, I get the following detection for a 3TB WD
with 4k sectors. This is via USB though:

Disk /dev/sdf: 3000.6 GB, 3000558944256 bytes
255 heads, 63 sectors/track, 45599 cylinders
Units = cylinders of 16065 * 4096 = 65802240 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

This is also listed in

# cat /sys/dev/block/8:80/queue/hw_sector_size
4096

Nice!

Arno

 

[Rod Speed]

David Brown wrote

Arno wrote

Do you mean to say you've found a 4K block disk that actually tells
the truth about itself?

It clearly doesnt on the heads, sectors per track or the cylinders either.

 

[Arno]

Do you mean to say you've found a 4K block disk that actually tells the
truth about itself?

Indeed. Or Linux is able to figure it out.

Arno

 

[Franc Zabkar]

Seems something is working right. With fdisk (util-linux-ng 2.17.2)
and kernel 2.6.38.8, I get the following detection for a 3TB WD
with 4k sectors. This is via USB though:

Disk /dev/sdf: 3000.6 GB, 3000558944256 bytes
255 heads, 63 sectors/track, 45599 cylinders
Units = cylinders of 16065 * 4096 = 65802240 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

This is also listed in

# cat /sys/dev/block/8:80/queue/hw_sector_size
4096

That's great info!

Could you please indulge me by obtaining the 512-byte ATA Identify
Device information block from the drive? This would help me greatly in
resolving, or at least understanding, several problems at WD's and
Seagate's forums.

I believe smartmontools should be able to do this, eg ...

smartctl -r ioctl,2 -a hda

You should see something like this:
http://www.users.on.net/~fzabkar/Smartctl/smart_debug.txt

AIUI, the Advanced Format features are reported in words 106, 117-118,
209.

These are described in section 7.16.4 of the following ATA standards
document.

Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf

- Franc Zabkar

 

[Arno]

Yes, but at least these lies have been common practice for many years.
They also make much less difference in practice (though partitions have
traditionally been aligned to cylinder boundaries).

The only remarkable thing is the correctly reported sector size,
which removes a lot of problems.

C/H/S do not cover it with ZBR anymore, as different cylinders
have different numbers of sectors. C/H/S has been a fiction
for quite some time and are just listed for user convenience and
this is not even information from the disk but calculated by fdisk.

The size info from the disk is 3000558944256 bytes.
Divide by sector size to get maximum LBA sector adddress.

Incidentally these facts about C/H/S have been known to everybody
that understands disk technology for a long, long time.

Arno

 

[Franc Zabkar]

The only remarkable thing is the correctly reported sector size,
which removes a lot of problems.

C/H/S do not cover it with ZBR anymore, as different cylinders
have different numbers of sectors. C/H/S has been a fiction
for quite some time and are just listed for user convenience and
this is not even information from the disk but calculated by fdisk.

The size info from the disk is 3000558944256 bytes.
Divide by sector size to get maximum LBA sector adddress.

I've been trying to understand what is happening in regards to device
detection for quite some time ago. Unfortunately I'm frustrated by a
lack of appropriate feedback. ;-)

AISI, there is a difference in the way that CHS parameters and sector
sizes are calculated or reported for external drives as compared with
internals.

According to the document below, a USB mass storage device reports the
following information via the Flexible Disk Mode Page (Mode Page 5) of
the SCSI MODE SENSE(10) Command.

Number of Heads
Sectors per Track
Bytes per Sector
Number of Cylinders

The SCSI READ CAPACITY command returns ...

Last Logical Block Address
Block Length in Bytes

Here is a thread where a user of a Seagate FreeAgent GoFlex 3TB
external drive has provided some usueful information:
http://forums.seagate.com/t5/GoFlex...-show-content-from-GoFlex-Desk-3tb/m-p/109026

The 3TB drive continues to report, via the ATA Identify Device
command, that it has 5.86 billion LBAs with a sector size of 512
bytes. However, it appears that the USB-SATA bridge chip inside the
enclosure fakes the drive's _logical_ geometry by reporting to the USB
host (via the abovementioned SCSI commands) that it has 4KB sectors
and 732 million LBAs.

I was hoping that your Identify Device report would provide more
information on the subject. ;-)

Universal Serial Bus Mass Storage Specification For Bootability:
http://www.usb.org/developers/devclass_docs/usb_msc_boot_1.0.pdf

- Franc Zabkar

 

[Rod Speed]

David Brown wrote

Rod Speed wrote

Yes, but at least these lies have been common practice for many years.
Irrelevant.

They also make much less difference in practice

Wrong, again.

(though partitions have traditionally been aligned to cylinder boundaries).

And the larger than reported sectors dont matter a damn.

 

[Rod Speed]

David Brown wrote

Rod Speed wrote

Tell me, then, what difference it would make if the drive reported
accurate information about heads, sectors and cylinders?

It isnt even possible with modern hard drives.

Theoretically you could make use of it to improve seek times, but
that would be an enormous complexity for very little gain, especially
as the number of sectors per track varies across the surface.

Irrelevant to what is being discussed.

Larger than reported sectors /do/ matter

Wrong. again.

- because writing a block that is smaller than a physical sector, or that overlaps physical sector boundaries, means
that the disk firmware must do read-modify-write cycles instead of straight writes.

Wrong. again.

The most obvious example is when the drive has 4K sectors but claims to have 512 byte sectors, and writes are
misaligned.

Trivially avoidable by not having them misaligned.

More generally, if drives start using 16K sectors and reporting 4K sizes, for example, then we will have similar
problems.

Wrong. again.

Partitions will be aligned, since the modern standard is 1 MB alignment.

Wrong. again.

But most disk accesses are done in 4K blocks because that matches the memory page size (on x86, amd64 at least).

Wrong. again.

As far as I know, Linux would be fine writing 16K blocks if the drive is honest about it, but lying here would cause
big performance issues.

Wrong. again.

 

[Arno]

On 12 Jul 2011 19:42:41 GMT, Arno <[email protected]> put finger to
keyboard and composed:

I've been trying to understand what is happening in regards to device
detection for quite some time ago. Unfortunately I'm frustrated by a
lack of appropriate feedback. ;-)

AISI, there is a difference in the way that CHS parameters and sector
sizes are calculated or reported for external drives as compared with
internals.

According to the document below, a USB mass storage device reports the
following information via the Flexible Disk Mode Page (Mode Page 5) of
the SCSI MODE SENSE(10) Command.

Aeh, yes. USB uses SCSI as storage command set, whule SATA
uses ATA. As the SCSI command set is far more well designed,
quite a few things work with it that do not work in ATA.

But this does have nothing to do with the drive being external
or internal. An internal SAS drive, e.g. will also use
the SCSI command set.

Arno

 

[Arno]

Tell me, then, what difference it would make if the drive reported
accurate information about heads, sectors and cylinders? Theoretically
you could make use of it to improve seek times, but that would be an
enormous complexity for very little gain, especially as the number of
sectors per track varies across the surface.

Indeed. It would have to report a whole table. Complexity
is the enemy of reliability and the designers wisely decided
to not go down that road. A system that really needs this can
still benchmark the drive.

Seems somebody has not been following the discussions in
various places or has not understood anything. Not even
worth an answer.

Arno

 

[Franc Zabkar]

Indeed. It would have to report a whole table.

This table would need to be updated every time a bad LBA was
reallocated to a spare sector.

- Franc Zabkar

 

[Franc Zabkar]

Aeh, yes. USB uses SCSI as storage command set, whule SATA
uses ATA.

But this does have nothing to do with the drive being external
or internal. An internal SAS drive, e.g. will also use
the SCSI command set.

The reason that I'm asking for your Identify Device data is so that I
can correlate them with the data in threads like the following:
http://community.wdc.com/t5/Desktop...between-WD20EARS-00MVWB0-and/m-p/219914#M6211

AISI, *any* 3TB drive, whether AF or not, can be accommodated by a
smart external USB enclosure. The bridge chip just needs to be able to
translate 512-byte LBAs to 4KB. As far as the host knows, the external
mass storage device is reporting that it uses 4KB LBAs. USB
transactions then proceed on this basis. However, the bridge chip
transparently converts these 4KB LBAs into the eight 512-byte LBAs
required by the drive, whether or not the drive is an AF model. In
fact Seagate's FreeAgent GoFlex 3TB external drive comes pre-formatted
with a single 3TB NTFS MBR partition that is claimed to be compatible
with Windows XP. AISI, Win XP should be able to handle 16TiB external
enclosures containing physical drives or RAIDs, provided that the
external device is configured for 4KB LBAs.

BTW, on your smartctl command line you may need to use a switch such
as ...

-d sat
-d sat,12
-d usbjmicron

- Franc Zabkar

 

[Bill James]

Franc Zabkar wrote

This table would need to be updated every time a bad LBA was
reallocated to a spare sector.

Nope, there are no spare sectors in that sense anymore, the only thing that changes is the LBA to CHS mapping.

 

[Arno]

On 13 Jul 2011 12:55:13 GMT, Arno <[email protected]> put finger to
keyboard and composed:

The reason that I'm asking for your Identify Device data is so that I
can correlate them with the data in threads like the following:
http://community.wdc.com/t5/Desktop...between-WD20EARS-00MVWB0-and/m-p/219914#M6211

Ah. Yes, I am willing to get you that data.

AISI, *any* 3TB drive, whether AF or not, can be accommodated by a
smart external USB enclosure. The bridge chip just needs to be able to
translate 512-byte LBAs to 4KB. As far as the host knows, the external
mass storage device is reporting that it uses 4KB LBAs. USB
transactions then proceed on this basis. However, the bridge chip
transparently converts these 4KB LBAs into the eight 512-byte LBAs
required by the drive, whether or not the drive is an AF model. In
fact Seagate's FreeAgent GoFlex 3TB external drive comes pre-formatted
with a single 3TB NTFS MBR partition that is claimed to be compatible
with Windows XP. AISI, Win XP should be able to handle 16TiB external
enclosures containing physical drives or RAIDs, provided that the
external device is configured for 4KB LBAs.

BTW, on your smartctl command line you may need to use a switch such
as ...

-d sat
-d sat,12
-d usbjmicron

"-d" sat on my sever with the debian default smartctl.
No need for that with current smartctl compiled form sources.

So you just need the output from "smartcl -i <device>"?
That would be the following:

smartctl -d sat -i /dev/sdf
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model: WDC WD30EZRS-00J99B0
Serial Number: WD-WCAWZ0158569
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Thu Jul 14 22:29:16 2011 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


Arno

 

[Franc Zabkar]

So you just need the output from "smartcl -i <device>"?
That would be the following:

smartctl -d sat -i /dev/sdf

I believe this line should do it:

smartctl -r ioctl,2 -a -d sat /dev/sdf

- Franc Zabkar

 

[Arno]

On 14 Jul 2011 20:33:44 GMT, Arno <[email protected]> put finger to
keyboard and composed:

I believe this line should do it:

smartctl -r ioctl,2 -a -d sat /dev/sdf

O.k., the Identidy Device section seems to be this one:

===== [IDENTIFY DEVICE] DATA START (BASE-16) =====
000-015: 7a 42 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 |zB.?7.......?...|
016-031: 00 00 00 00 20 20 20 20 57 20 2d 44 43 57 57 41 |.... W -DCWWA|
032-047: 30 5a 35 31 34 33 30 37 00 00 00 00 32 00 30 38 |0Z514307....2.08|
048-063: 30 2e 41 30 30 38 44 57 20 43 44 57 30 33 5a 45 |0.A008DW CDW03ZE|
064-079: 53 52 30 2d 4a 30 39 39 30 42 20 20 20 20 20 20 |SR0-J0990B |
080-095: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 | ..|
096-111: 00 00 00 2f 01 40 00 00 00 00 07 00 ff 3f 10 00 |.../.@.......?..|
112-127: 3f 00 10 fc fb 00 00 01 ff ff ff 0f 00 00 07 01 |?...............|
128-143: 03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 |..x.x.x.x.......|
144-159: 00 00 00 00 00 00 1f 00 06 17 00 00 44 00 40 00 |............D.@.|
160-175: fe 01 00 00 6b 74 61 7f 23 41 69 74 41 bc 23 41 |....kta.#AitA.#A|
176-191: 7f 00 ff 00 ff 00 00 00 fe ff 00 00 fe 80 00 00 |................|
192-207: 00 00 00 00 00 00 00 00 b0 a3 50 5d 01 00 00 00 |..........P]....|
208-223: 00 00 00 00 03 60 00 00 01 50 e2 4e 02 b0 b2 b7 |.....`...P.N....|
224-239: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 40 |...............@|
240-255: 18 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.@..............|
256-271: 21 00 00 00 00 00 00 00 00 00 fe 16 0d 01 00 00 |!...............|
272-287: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 |................|
288-303: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
304-319: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
320-335: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
336-351: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
352-367: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
368-383: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
384-399: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
400-415: 00 00 00 00 00 00 00 00 00 00 00 00 35 30 00 00 |............50..|
416-431: 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............|
432-447: 00 00 00 00 00 00 00 00 00 00 00 00 1e 10 00 00 |................|
448-463: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
464-479: 00 00 00 00 01 00 00 10 00 00 00 00 00 00 00 00 |................|
480-495: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
496-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 e9 |................|
===== [IDENTIFY DEVICE] DATA END (512 Bytes) =====

Is that what you need?

Arno

 

[Franc Zabkar]

O.k., the Identidy Device section seems to be this one:

Thanks again.

I have reformatted your data so that it can be more easily correlated
against the documentation in section 7.16.4 of the following ATA
standards document.

Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf

Word# 0 1 2 3 4 5 6 7 8 9
________________________________________________________
0 427A 3FFF C837 0010 0000 0000 003F 0000 0000 0000
10 2020 2020 2057 442D 5743 4157 5A30 3135 3334 3730
20 0000 0000 0032 3830 2E30 3041 3830 5744 4320 5744
30 3330 455A 5253 2D30 304A 3939 4230 2020 2020 2020
40 2020 2020 2020 2020 2020 2020 2020 8010 0000 2F00
50 4001 0000 0000 0007 3FFF 0010 003F FC10 00FB 0100
60 FFFF 0FFF 0000 0107 0003 0078 0078 0078 0078 0000
70 0000 0000 0000 0000 0000 001F 1706 0000 0044 0040
80 01FE 0000 746B 7F61 4123 7469 BC41 4123 007F 00FF
90 00FF 0000 FFFE 0000 80FE 0000 0000 0000 0000 0000
100 A3B0 5D50 0001 0000 0000 0000 6003 0000 5001 4EE2
110 B002 B7B2 0000 0000 0000 0000 0000 0000 0000 4018
120 4018 0000 0000 0000 0000 0000 0000 0000 0021 0000
130 0000 0000 0000 16FE 010D 0000 0000 0000 0000 0000
140 0000 0000 0004 0000 0000 0000 0000 0000 0000 0000
150 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
160 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
170 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
180 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
190 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
200 0000 0000 0000 0000 0000 0000 3035 0000 0000 4000
210 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
220 0000 0000 101E 0000 0000 0000 0000 0000 0000 0000
230 0000 0000 0000 0000 0001 1000 0000 0000 0000 0000
240 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
250 0000 0000 0000 0000 0000 E9A5

Word 106 (0x6003) is reporting that the ratio of physical sector size
to logical sector size is 8:1.

Words 100-103 are reporting a total of 0x15D50A3B0 LBAs.

This means that your drive is an Advanced Format model, but it is
still using 512-byte emulation (512e).

0x15d50a3b0 LBAs x 512 bytes/LBA = 3,000,592,982,016 bytes

This means that the bridge chip inside the enclosure is faking the
drive's geometry, or correcting it, depending on your point of view.

I suspect that you may find that the file system on your drive (NTFS?)
is set up for 4KB sector sizes rather than 512 bytes. It would be
interesting to dump the partition table and boot sector.

AFAICS, the translation regime is as follows:

4KB file -- PC <-- 4KB --> bridge <-- 8 x 512e --> HDD -- 4KB physical
system LBA IC LBAs sector

Could I impose on you once again for the above information? I believe
GParted should be able to tell us what we need to know about the
partition table. In the case of Seagate's 3TB GoFlex drive, the boot
sector was at LBA 7. WD may have chosen a different LBA. I believe you
should be able to use dd to capture the first logical track.

A lsusb or usbview report would also be interesting.

- Franc Zabkar

 

[Arno]

On 15 Jul 2011 12:14:37 GMT, Arno <[email protected]> put finger to
keyboard and composed:

Thanks again.

I have reformatted your data so that it can be more easily correlated
against the documentation in section 7.16.4 of the following ATA
standards document.

Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf

Word# 0 1 2 3 4 5 6 7 8 9
________________________________________________________
0 427A 3FFF C837 0010 0000 0000 003F 0000 0000 0000
10 2020 2020 2057 442D 5743 4157 5A30 3135 3334 3730
20 0000 0000 0032 3830 2E30 3041 3830 5744 4320 5744
30 3330 455A 5253 2D30 304A 3939 4230 2020 2020 2020
40 2020 2020 2020 2020 2020 2020 2020 8010 0000 2F00
50 4001 0000 0000 0007 3FFF 0010 003F FC10 00FB 0100
60 FFFF 0FFF 0000 0107 0003 0078 0078 0078 0078 0000
70 0000 0000 0000 0000 0000 001F 1706 0000 0044 0040
80 01FE 0000 746B 7F61 4123 7469 BC41 4123 007F 00FF
90 00FF 0000 FFFE 0000 80FE 0000 0000 0000 0000 0000
100 A3B0 5D50 0001 0000 0000 0000 6003 0000 5001 4EE2
110 B002 B7B2 0000 0000 0000 0000 0000 0000 0000 4018
120 4018 0000 0000 0000 0000 0000 0000 0000 0021 0000
130 0000 0000 0000 16FE 010D 0000 0000 0000 0000 0000
140 0000 0000 0004 0000 0000 0000 0000 0000 0000 0000
150 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
160 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
170 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
180 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
190 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
200 0000 0000 0000 0000 0000 0000 3035 0000 0000 4000
210 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
220 0000 0000 101E 0000 0000 0000 0000 0000 0000 0000
230 0000 0000 0000 0000 0001 1000 0000 0000 0000 0000
240 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
250 0000 0000 0000 0000 0000 E9A5

Word 106 (0x6003) is reporting that the ratio of physical sector size
to logical sector size is 8:1.

Words 100-103 are reporting a total of 0x15D50A3B0 LBAs.

This means that your drive is an Advanced Format model, but it is
still using 512-byte emulation (512e).

I see.

0x15d50a3b0 LBAs x 512 bytes/LBA = 3,000,592,982,016 bytes

This means that the bridge chip inside the enclosure is faking the
drive's geometry, or correcting it, depending on your point of view.

You think it is the bridge chip? Would make sense as
Linux does report logical and physical separately. Maybe
it is because larger sectors do work with USB, as they
have been used in some SCSI drives for a long time.
I used to have a SCSI MOD drive with some disks
that had 2k sectors. I think the '-b <size>' option,
originally only up to 2k, got added to Linux fdisk,
because I complained ;-)

I suspect that you may find that the file system on your drive (NTFS?)
is set up for 4KB sector sizes rather than 512 bytes. It would be
interesting to dump the partition table and boot sector.

Ah, too late. I zeroed them out to remove anything unpleasant
that WD may have left there. They are formatted ext3 now
(no partitions, and default block size is 4k in ext3).

AFAICS, the translation regime is as follows:

4KB file -- PC <-- 4KB --> bridge <-- 8 x 512e --> HDD -- 4KB physical
system LBA IC LBAs sector

Makes sense to me.

Could I impose on you once again for the above information? I believe
GParted should be able to tell us what we need to know about the
partition table. In the case of Seagate's 3TB GoFlex drive, the boot
sector was at LBA 7. WD may have chosen a different LBA. I believe you
should be able to use dd to capture the first logical track.

Sorry, see above.

A lsusb or usbview report would also be interesting.

That I can give you, see below.

Arno

----
Bus 008 Device 006: ID 1058:1130 Western Digital Technologies, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x1058 Western Digital Technologies, Inc.
idProduct 0x1130
bcdDevice 10.12
iManufacturer 1 Western Digital
iProduct 2 My Book 1130
iSerial 3 574341575A30313532353330
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 44
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 16
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled

 

[Franc Zabkar]

I see.



You think it is the bridge chip?

I would think that Linux gets the drive's parameters via the SCSI Mode
Sense and Read Capacity commands, in which case it must be the bridge
chip that is responsible for providing this information.

wMaxPacketSize 0x0400 1x 1024 bytes
wMaxPacketSize 0x0400 1x 1024 bytes

I expect this means that each 4KB LBA is split up into 4 data packets.
(???)

- Franc Zabkar

 

[Arno]

On 16 Jul 2011 01:10:11 GMT, Arno <[email protected]> put finger to
keyboard and composed:

I would think that Linux gets the drive's parameters via the SCSI Mode
Sense and Read Capacity commands, in which case it must be the bridge
chip that is responsible for providing this information.

Good point. If these cases were a little easier to open,
I could do a comparison by direct attachment. But unfortunately
they are not.

I expect this means that each 4KB LBA is split up into 4 data packets.
(???)

Seems so.

Arno