USB-Storage und mehr als 2 TB in einem Medium

[Marc Haber]

Hallo,

ich habe hier ein USB2-SATA-Gehäuse mit Initio-Bridge:

|Bus 001 Device 084: ID 13fd:1340 Initio Corporation Hi-Speed USB to SATA Bridge

Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
erkannt:

|Apr 3 22:49:29 swivel kernel: [426945.712685] sd 25:0:0:0: Attached scsi generic sg2 type 0
|Apr 3 22:49:29 swivel kernel: [426945.713080] sd 25:0:0:0: [sdc] 1565565872 512-byte logical blocks: (801 GB/746 GiB)
|Apr 3 22:49:29 swivel kernel: [426945.713981] sd 25:0:0:0: [sdc] Write Protect is off
|Apr 3 22:49:29 swivel kernel: [426945.713993] sd 25:0:0:0: [sdc] Mode Sense: 21 00 00 00
|Apr 3 22:49:29 swivel kernel: [426945.714939] sd 25:0:0:0: [sdc] No Caching mode page present
|Apr 3 22:49:29 swivel kernel: [426945.714947] sd 25:0:0:0: [sdc] Assuming drive cache: write through
|Apr 3 22:49:29 swivel kernel: [426945.717689] sd 25:0:0:0: [sdc] No Caching mode page present
|Apr 3 22:49:29 swivel kernel: [426945.717703] sd 25:0:0:0: [sdc] Assuming drive cache: write through
|Apr 3 22:49:29 swivel kernel: [426945.766286] sdc:
|Apr 3 22:49:29 swivel kernel: [426945.769252] sd 25:0:0:0: [sdc] No Caching mode page present
|Apr 3 22:49:29 swivel kernel: [426945.769264] sd 25:0:0:0: [sdc] Assuming drive cache: write through
|Apr 3 22:49:29 swivel kernel: [426945.769272] sd 25:0:0:0: [sdc] Attached SCSI disk

Direkt per SATA angeschlossen, wird die Platte ordentlich erkannt und
funktioniert prima. Die per direktem Anschluß erzeugte Partitionierung
wird in dem SATA-Gehäuse nicht erkannt.

Schließe ich das SATA-Gehäuse mit der 3-TB-Platte an ein Windows 7 an,
wird die Platte ordentlich mit 3 TB Kapazität erkannt und auch die
Partitionierung wird vom Windows gesehen. Mehr habe ich nicht
probiert, da ein ext4-Dateisystem drauf ist.

Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
USB-Storage ein 2-TB-Limit besteht? Warum funktioniert es unter
Windows?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Helmut Hullen]

Hallo, Marc,

Du meintest am 03.04.13:

> ich habe hier ein USB2-SATA-Gehäuse mit Initio-Bridge:

> |Bus 001 Device 084: ID 13fd:1340 Initio Corporation Hi-Speed USB to
> SATA Bridge

> Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
> erkannt:

[...]

> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
> USB-Storage ein 2-TB-Limit besteht?

Liegt am Chipsatz. Nicht an Linux.

Derzeit sieht es so aus, als ob nur wenige USB-SATA-Adapter oder -
Dockingstationen die 3-Terabyte-Platten verkraften; wenn sie es können,
dann steht das ausdrücklich in der Beschreibung drin.

Und bei Komplettgehäusen tricksen einige Hersteller mit der Blockgrösse
- ist eine andere Baustelle.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
>> USB-Storage ein 2-TB-Limit besteht?
>
>Liegt am Chipsatz. Nicht an Linux.

Und warum funktioniert es dann mit Windows?

>Derzeit sieht es so aus, als ob nur wenige USB-SATA-Adapter oder -
>Dockingstationen die 3-Terabyte-Platten verkraften; wenn sie es können,
>dann steht das ausdrücklich in der Beschreibung drin.

Und warum funktioniert es dann mit Windows?

[Helmut Hullen]

Hallo, Marc,

Du meintest am 04.04.13:

>>> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
>>> USB-Storage ein 2-TB-Limit besteht?
>> Liegt am Chipsatz. Nicht an Linux.

> Und warum funktioniert es dann mit Windows?

Vielleicht Trickserei mit der Blockgrösse. Die Berichte über einzelne
Komplettgeräte lassen so etwas erahnen.
Ich benutze hier stets Adapter/Dockingstationen mit "normalen" SATA-
Platten, da benehmen sich Linux und Windows (jedenfalls bei meinen
Experimenten) gleich.

Ach ja: Windows XP benimmt sich da anscheinend auch noch anders/zickiger
als Vista und Nachfolger.

--------------------------

Wenn Du ein wenig experimentieren willst:
USB-Dockingstation: Orico 6618SUS3 kann mit grossen Platten umgehen,
USB-SATA-Adapter (ohne Netzteil): Delock 61754 kann das auch (eSATA-
Anschluss).

In beiden Fällen: USB 3.0

[Henning Paul]

Marc Haber schrieb:

> Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
> erkannt:

Google sagt, damit bist Du nicht er einzige.

> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
> USB-Storage ein 2-TB-Limit besteht? Warum funktioniert es unter
> Windows?

Ob es wirklich funktioniert, da bin ich mir nicht so sicher. Vielleicht
ignoriert Windows die Größe, die vom USB-SATA-Wandler gemeldet wird und
befragt die Platte selbst. Dann wäre es aber immer noch möglich, dass
ohne Warnung auf die Platte modulo 2TiB(=2,2TB) geschrieben wird. Wäre
nicht das erste Mal bei Windows.

Zumindest berichtet Google von Leuten, die das Problem durch Austausch
des USB-SATA-Wandlers behoben haben.

Gruß
Henning (bei dem eine spontan getestete "152d:2338 JMicron Technology
Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA
Combo Bridge" dasselbe Problem zeigt)

[Henning Paul]

Helmut Hullen schrieb:

> Du meintest am 04.04.13:
>
>>>> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
>>>> USB-Storage ein 2-TB-Limit besteht?
>>> Liegt am Chipsatz. Nicht an Linux.
>
>> Und warum funktioniert es dann mit Windows?
>
> Vielleicht Trickserei mit der Blockgrösse. Die Berichte über einzelne
> Komplettgeräte lassen so etwas erahnen.

Die macht dann aber schon der USB-SATA-Wandler.

Gruß
Henning

[Marc Haber]

Henning Paul <henni...@gmx.de> wrote:
>Marc Haber schrieb:
>> Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
>> erkannt:
>
>Google sagt, damit bist Du nicht er einzige.
>
>> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
>> USB-Storage ein 2-TB-Limit besteht? Warum funktioniert es unter
>> Windows?
>

>Zumindest berichtet Google von Leuten, die das Problem durch Austausch
>des USB-SATA-Wandlers behoben haben.

Was möchtest Du damit bezwecken, dass Du in jedem zweiten Satz auf
Google verweist? Meinst Du, ich hätte die substanzlosen Webforen nicht
schon gefunden, bevor ich hier nach technisch substanziierten Aussagen
auf die Suche ging?

Das mit modulo 2 TB werde ich nächstens mal ausprobieren, ich hab'
aktuell eine 3-TB-Platte noch nicht wieder mit wichtigen Daten
gefüllt.

Einfach ein anderes Gehäuse nehmen ist dummerweise nichttrivial, ich
habe etliche identische davon, und diese Gehäuse haben andere
Vorteile, die mich dazu veranlassen, sie nicht aufgrund irgendwelches
Webforum-Lalls auszumustern.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Vielleicht Trickserei mit der Blockgrösse. Die Berichte über einzelne
>Komplettgeräte lassen so etwas erahnen.

Und wie soll die funktionieren?

>Ich benutze hier stets Adapter/Dockingstationen mit "normalen" SATA-
>Platten, da benehmen sich Linux und Windows (jedenfalls bei meinen
>Experimenten) gleich.

Was ist eine normale und was ist eine unnormale SATA-Platte?

>Ach ja: Windows XP benimmt sich da anscheinend auch noch anders/zickiger
>als Vista und Nachfolger.

Was man einem OS, das auf den Markt kam, als 10 GB eine "wirklich
fette Platte" waren, nicht wirklich nachtragen kann.

>Wenn Du ein wenig experimentieren willst:
>USB-Dockingstation: Orico 6618SUS3 kann mit grossen Platten umgehen,
>USB-SATA-Adapter (ohne Netzteil): Delock 61754 kann das auch (eSATA-
>Anschluss).

Es wäre jedenfalls erstmal einen Versuch wert, das Fantec-Gehäuse mal
über eSATA anzubinden. Dort, wo ich es eigentlich benutzen will, nützt
mir das zwar nicht, aber um akademische Ergebnisse zu erhalten,
probieren wir das mal.

Die 6618US3 scheint es nicht mehr zu geben; man findet zwar jede Menge
Bilder, aber weder bei Amazon noch bei Geizhals hat 6618US3
irgendwelche Ergebnisse. Der Delock riecht mir nach "Sucht nach
Ärger", weil man dann von USB auf eSATA auf SATA wandelt und sich noch
das Netzteilproblem einhandelt.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 04.04.13:

>> Vielleicht Trickserei mit der Blockgrösse. Die Berichte über
>> einzelne Komplettgeräte lassen so etwas erahnen.

> Und wie soll die funktionieren?

>> Ich benutze hier stets Adapter/Dockingstationen mit "normalen" SATA-
>> Platten, da benehmen sich Linux und Windows (jedenfalls bei meinen
>> Experimenten) gleich.

> Was ist eine normale und was ist eine unnormale SATA-Platte?

"normal": Blockgrösse 512 Byte.

>> Wenn Du ein wenig experimentieren willst:
>> USB-Dockingstation: Orico 6618SUS3 kann mit grossen Platten umgehen,
>> USB-SATA-Adapter (ohne Netzteil): Delock 61754 kann das auch (eSATA-
>> Anschluss).

> Es wäre jedenfalls erstmal einen Versuch wert, das Fantec-Gehäuse mal
> über eSATA anzubinden. Dort, wo ich es eigentlich benutzen will,
> nützt mir das zwar nicht, aber um akademische Ergebnisse zu erhalten,
> probieren wir das mal.

> Die 6618US3 scheint es nicht mehr zu geben; man findet zwar jede
> Menge Bilder, aber weder bei Amazon noch bei Geizhals hat 6618US3
> irgendwelche Ergebnisse.

Hmmm - Amazon-Suche nach

Dockingstation USB SATA 3TB

liefert einiges in der Gegend, könnte sein, dass das "ORICO 9618SUS" der
Nachfolger ist.

> Der Delock riecht mir nach "Sucht nach
> Ärger", weil man dann von USB auf eSATA auf SATA wandelt und sich
> noch das Netzteilproblem einhandelt.

Funktioniert hier brav. Netzteil/SATA-Spannungsversorgung ist auch bei
einigen anderen Varianten eines der lästigen Nebenprobleme.

Hier habe ich inzwischen etliche Adapter auch für die
Spannungsversorgung und für die Umsetzung SATA-eSATA ...

Das kommt davon, wenn der jeweilige Hauptrechner ein Laptop ist - dann
entwickelt sich drumherum ein Drahtverhau. Im Tower lässt sich so etwas
besser verstecken.

[Joseph Terner]

On Thu, 04 Apr 2013 18:59:00 +0200, Marc Haber wrote:
> Henning Paul <henni...@gmx.de> wrote:
>>Marc Haber schrieb:
>>> Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
>>> erkannt:
>>
>>Google sagt, damit bist Du nicht er einzige.
>>
>>> Ist das eine bekannte Einschränkung des Linux-Kernels, dass bei
>>> USB-Storage ein 2-TB-Limit besteht? Warum funktioniert es unter
>>> Windows?

Datenschredderei durch 128-GiB- oder 2-TiB-Clipping gehört bei Windows
zum Alltag.

>>Zumindest berichtet Google von Leuten, die das Problem durch Austausch
>>des USB-SATA-Wandlers behoben haben.
>
> Was möchtest Du damit bezwecken, dass Du in jedem zweiten Satz auf
> Google verweist? Meinst Du, ich hätte die substanzlosen Webforen nicht
> schon gefunden, bevor ich hier nach technisch substanziierten Aussagen
> auf die Suche ging?

Ich habe zwei Dockingstationen mit Initio-Controller und die Hersteller
(einmal Sharkoon, einmal Raidsonic) weisen sie offiziell als inkompatibel
mit 3TB-Festplatten aus:

<http://www.sharkoon.com/?q=en/content/sata-quickport>

<http://www.raidsonic.de/de/products/details.php?we_objectID=6069>
(unter <javascript:animatedcollapse.show('tec_log')>)

Obwohl ich das mangels 3TB-Festplatten selbst nicht nachprüfen kann, geh
ich mal davon aus, daß die das getestet haben und das Produkt
anderenfalls weiter verkauft hätten.

Joseph

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Du meintest am 04.04.13:

>> Was ist eine normale und was ist eine unnormale SATA-Platte?
>
>"normal": Blockgrösse 512 Byte.

Das liegt hier ausweislich des Syslogs zweifelsfrei vor.

[Marc Haber]

Marc Haber <mh+usene...@zugschl.us> wrote:
>Es wäre jedenfalls erstmal einen Versuch wert, das Fantec-Gehäuse mal
>über eSATA anzubinden. Dort, wo ich es eigentlich benutzen will, nützt
>mir das zwar nicht, aber um akademische Ergebnisse zu erhalten,
>probieren wir das mal.

Also: Mit eSATA funktioniert die 3-TB-Platte unter Linux mit voller
Kapazität.

Unter Windows passiert mit USB 2.0 etwas erstaunlich negativ
überraschendes: Nachdem man in einer 50 Stunden dauernden Aktion 2,3
GB auf die Platte geschrieben hat (Restspeicher ca. 730 GB), bucht
sich die Platte einfach aus; jegliche Zugriffe erzeugen nur noch
Fehlermeldungen, und neu erkannt wird sie dann auch nur noch mit < 1
GB Kapazität.

Unter Linux ist das Verhalten unverändert, und wenn ich die Platte
nach dem Windows-Überlauf per eSATA an Linux anschließe, wird sie zwar
mit voller Kapazität erkannt, aber die Partitionstabelle ist futsch.

=> Es passiert Clipping, Linux macht es richtig, Windows lässt den
Anwender bis zur Katastrophe im guten Glauben.

[Henning Paul]

Marc Haber schrieb:

> Also: Mit eSATA funktioniert die 3-TB-Platte unter Linux mit voller
> Kapazität.

Alles andere hätte mich auch gewundert.

> Unter Windows passiert mit USB 2.0 etwas erstaunlich negativ
> überraschendes: Nachdem man in einer 50 Stunden dauernden Aktion 2,3
> GB auf die Platte geschrieben hat (Restspeicher ca. 730 GB), bucht
> sich die Platte einfach aus; jegliche Zugriffe erzeugen nur noch
> Fehlermeldungen, und neu erkannt wird sie dann auch nur noch mit < 1
> GB Kapazität.
>
> Unter Linux ist das Verhalten unverändert, und wenn ich die Platte
> nach dem Windows-Überlauf per eSATA an Linux anschließe, wird sie zwar
> mit voller Kapazität erkannt, aber die Partitionstabelle ist futsch.
>
> => Es passiert Clipping, Linux macht es richtig, Windows lässt den
> Anwender bis zur Katastrophe im guten Glauben.

Da muss ich jetzt klugscheißen, das ist kein Clipping, das ist ein
Wraparound. Bei Clipping würden die Zugriffe jenseits 2,2TB im Nirvana
landen, hier landen sie modulo 2TiB auf der Platte.

Gruß
Henning

[Dirk Thierbach]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Unter Windows passiert mit USB 2.0 etwas erstaunlich negativ
> überraschendes: Nachdem man in einer 50 Stunden dauernden Aktion 2,3
> GB auf die Platte geschrieben hat (Restspeicher ca. 730 GB), bucht
> sich die Platte einfach aus; jegliche Zugriffe erzeugen nur noch
> Fehlermeldungen, und neu erkannt wird sie dann auch nur noch mit < 1
> GB Kapazität.

> Unter Linux ist das Verhalten unverändert, und wenn ich die Platte
> nach dem Windows-Überlauf per eSATA an Linux anschließe, wird sie zwar
> mit voller Kapazität erkannt, aber die Partitionstabelle ist futsch.
>
> => Es passiert Clipping, Linux macht es richtig, Windows lässt den
> Anwender bis zur Katastrophe im guten Glauben.

Mit anderen Worten, die bisherige Diagnose war wohl richtig: Die
SATA-USB-Bridge ist Schuld, weil sie mit 3 TB-Platten nicht richtig
arbeitet. Linux merkt das, Windows merkt es nicht mal, bis es dann
kracht.

Also am besten eine andere Bridge nehmen, von der man weiss, dass sie
mit grossen Platten auch funktioniert.

- Dirk

[Marc Haber]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>Mit anderen Worten, die bisherige Diagnose war wohl richtig: Die
>SATA-USB-Bridge ist Schuld, weil sie mit 3 TB-Platten nicht richtig
>arbeitet. Linux merkt das, Windows merkt es nicht mal, bis es dann
>kracht.

Genau.

>Also am besten eine andere Bridge nehmen, von der man weiss, dass sie
>mit grossen Platten auch funktioniert.

Was leider auch bedeutet, wieder ein anderes Netzteil :-(

[Martin Schoenbeck]

Hallo Dirk,

Dirk Thierbach schrieb:

> Mit anderen Worten, die bisherige Diagnose war wohl richtig: Die
> SATA-USB-Bridge ist Schuld, weil sie mit 3 TB-Platten nicht richtig
> arbeitet. Linux merkt das, Windows merkt es nicht mal, bis es dann
> kracht.

Das mu� nicht sein. Wenn die Brigde nur Befehle mit 32-Bit-Sektornummern
unterst�tzt, dann ist das kein Fehler des Adapter, falls dann jemand
512-Byte-Sektoren oberhalb 2 TiB lesen will und die n�tigen Bits nicht in
das Feld f�r die Sektornummer reinkriegt.

Gru� Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die pa�t so.

[Marc Haber]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>Mit anderen Worten, die bisherige Diagnose war wohl richtig

Genau.

[Marc Haber]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>Dirk Thierbach schrieb:
>> Mit anderen Worten, die bisherige Diagnose war wohl richtig: Die
>> SATA-USB-Bridge ist Schuld, weil sie mit 3 TB-Platten nicht richtig
>> arbeitet. Linux merkt das, Windows merkt es nicht mal, bis es dann
>> kracht.
>

>Das muß nicht sein. Wenn die Brigde nur Befehle mit 32-Bit-Sektornummern
>unterstützt, dann ist das kein Fehler des Adapter, falls dann jemand
>512-Byte-Sektoren oberhalb 2 TiB lesen will und die nötigen Bits nicht in
>das Feld für die Sektornummer reinkriegt.

Eigentlich würde ich vom OS erwarten, dass es bemerkt, dass die Bridge
keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
oder nur als 2-TB-Platte erkennt. Wobei ich mir für beide
Möglichkeiten Szenarien vorstellen kann, in denen das Verhalten
ungeschickt ist.

Einfach irgendwas erkennen und dann Daten schreddern finde ich nicht
akzeptabel.

[Martin Schoenbeck]

Hallo Marc,

Marc Haber schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>>Dirk Thierbach schrieb:
>>> Mit anderen Worten, die bisherige Diagnose war wohl richtig: Die
>>> SATA-USB-Bridge ist Schuld, weil sie mit 3 TB-Platten nicht richtig
>>> arbeitet. Linux merkt das, Windows merkt es nicht mal, bis es dann
>>> kracht.
>>

>>Das mu� nicht sein. Wenn die Brigde nur Befehle mit 32-Bit-Sektornummern
>>unterst�tzt, dann ist das kein Fehler des Adapter, falls dann jemand
>>512-Byte-Sektoren oberhalb 2 TiB lesen will und die n�tigen Bits nicht in
>>das Feld f�r die Sektornummer reinkriegt.
>

> Eigentlich w�rde ich vom OS erwarten, dass es bemerkt, dass die Bridge

> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt

> oder nur als 2-TB-Platte erkennt. Wobei ich mir f�r beide
> M�glichkeiten Szenarien vorstellen kann, in denen das Verhalten

> ungeschickt ist.
>
> Einfach irgendwas erkennen und dann Daten schreddern finde ich nicht
> akzeptabel.

Sehe ich genauso. Ich wollte nur darauf hinweisen, da� das dann kein Fehler
des Ger�ts ist. Sondern eben des BS.

[Dirk Thierbach]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Eigentlich würde ich vom OS erwarten, dass es bemerkt, dass die Bridge
> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
> oder nur als 2-TB-Platte erkennt. Wobei ich mir für beide
> Möglichkeiten Szenarien vorstellen kann, in denen das Verhalten
> ungeschickt ist.

> Einfach irgendwas erkennen und dann Daten schreddern finde ich nicht
> akzeptabel.

Code fuer einen Test schreiben, einen Patch machen und einschicken.
Oder zumindest in einem Bugreport das Problem beschreiben. Wobei dann
die urspruenglichen Autoren immer noch sagen koennen: "Es ist nicht
unser Problem, wenn die Hardware buggy ist, und im Moment haben wir
keine Zeit, fuer jede kaputte Hardware einen Workaround zu schreiben
(wenn nicht mal klar ist, was der tun soll), insbesondere wenn wir
keinen Zugriff auf die Hardware haben."

- Dirk

[Dirk Thierbach]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
> Sehe ich genauso. Ich wollte nur darauf hinweisen, daß das dann kein Fehler
> des Geräts ist. Sondern eben des BS.

Das BS kann in der Regel nichts dafuer, wenn eine Hardware-Zwischenschicht
behaupet "ich kann das uebertragen", bei der Uebertragung dann aber
nicht alles uebertraegt. Weil der Hardware-Designer diesen Fall nicht
abgedeckt hat und irgendwelche Puffer oder Register zu klein sind.
Was erstmal die wahrscheinlichste Quelle fuer den Fehler ist.

- Dirk

[Martin Schoenbeck]

Hallo Dirk,

Dirk Thierbach schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>> Sehe ich genauso. Ich wollte nur darauf hinweisen, da� das dann kein Fehler
>> des Ger�ts ist. Sondern eben des BS.

>
> Das BS kann in der Regel nichts dafuer, wenn eine Hardware-Zwischenschicht
> behaupet "ich kann das uebertragen", bei der Uebertragung dann aber
> nicht alles uebertraegt.

Liest Du eigentlich, worauf Du antwortest? Und warum eigentlich nicht?

> Weil der Hardware-Designer diesen Fall nicht
> abgedeckt hat und irgendwelche Puffer oder Register zu klein sind.
> Was erstmal die wahrscheinlichste Quelle fuer den Fehler ist.

Na Du mu�t Dich ja auskennen.

Ich habe in den Bits von USB-SATA-Konvertern leider noch nicht
herumgefummelt, deshalb kann ich da leider �berhaupt keine
Wahrscheinlichkeit f�r die Ursache eines solchen Problems angeben. Was ich
aber sicher kann, ist, die Aussage machen, da� die von mir dargestellte
Variante kein Fehler des Konverters ist.

[Martin Schoenbeck]

Hallo Heiko,

Heiko Schlenker schrieb:

> * Marc Haber <mh+usene...@zugschl.us> schrieb:
>> Eigentlich w�rde ich vom OS erwarten, dass es bemerkt, dass die Bridge

>> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
>> oder nur als 2-TB-Platte erkennt.
>

> Ein OS hat eigentlich keine Chance, wenn die Hardware l�gt.

Marc bezog sich ja auf meine Darstellung eines Fehlerszenarios. Bist Du so
gut, einmal zu erl�utern, wo da die Hardware l�gen m��te, um das BS diesen
Fehler machen zu lassen?

[Hermann Riemann]

Marc Haber schrieb:

> Wenn ich dort eine 3-TB-Platte hineinstecke,
> wird sie nur mit 801 GB erkannt:

> Schließe ich das SATA-Gehäuse mit der 3-TB-Platte an ein Windows 7 an,
> wird die Platte ordentlich mit 3 TB Kapazität erkannt und auch die
> Partitionierung wird vom Windows gesehen. Mehr habe ich nicht
> probiert, da ein ext4-Dateisystem drauf ist.

Und womit hast du partitioniert?

Hermann
der seine nur unter Linux verwendete USB-Platten
erst mit Linux partitioniert, dann formatiert,
dann mind. einen Ordner anlegt, den er mit chmod und chown
die gleichen Eigenschaften wie $home zuordnet.

--
http://www.Hermann-Riemann.de

[Martin Schoenbeck]

Hallo Heiko,

Heiko Schlenker schrieb:

> * Martin Schoenbeck <ms.usene...@schoenbeck.de> schrieb:

>> Heiko Schlenker schrieb:
>>> * Marc Haber <mh+usene...@zugschl.us> schrieb:
>>>> Eigentlich w�rde ich vom OS erwarten, dass es bemerkt, dass die Bridge
>>>> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
>>>> oder nur als 2-TB-Platte erkennt.
>>>
>>> Ein OS hat eigentlich keine Chance, wenn die Hardware l�gt.
>>
>> Marc bezog sich ja auf meine Darstellung eines Fehlerszenarios. Bist Du so
>> gut, einmal zu erl�utern, wo da die Hardware l�gen m��te, um das BS diesen
>> Fehler machen zu lassen?
>

> Die "Hardware" akzeptiert klaglos Eingabedaten, die sie tats�chlich
> nicht korrekt verarbeiten kann.

Lies doch erstmal, wie ich das Szenario beschrieb. Wie soll denn die
Hardware in einem Befehl, in dem nur 32 Bit Platz haben, Eingabedaten mit
mehr als 32 Bit akzeptieren?

[Marc Haber]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Eigentlich würde ich vom OS erwarten, dass es bemerkt, dass die Bridge
>> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
>> oder nur als 2-TB-Platte erkennt. Wobei ich mir für beide
>> Möglichkeiten Szenarien vorstellen kann, in denen das Verhalten
>> ungeschickt ist.
>
>> Einfach irgendwas erkennen und dann Daten schreddern finde ich nicht
>> akzeptabel.
>
>Code fuer einen Test schreiben, einen Patch machen und einschicken.

Für Windows?

[Dirk Thierbach]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
> Liest Du eigentlich, worauf Du antwortest?

Ja. Hier noch mal die Stelle:

: Das muß nicht sein. Wenn die Brigde nur Befehle mit 32-Bit-Sektornummern
: unterstützt, dann ist das kein Fehler des Adapter, falls dann jemand
: 512-Byte-Sektoren oberhalb 2 TiB lesen will und die nötigen Bits nicht in
: das Feld für die Sektornummer reinkriegt.

Dieser Fall liegt nicht vor, da der Linux-Kernel (sd.c) *immer* ein
READ/WRITE(16) (64 bit) erzwingt, wenn die Blocknummer zu gross fuer
READ/WRITE(10) ist. (Zeile 1014 bei 3.7.1 sowohl fuer READ wie WRITE).

> Ich habe in den Bits von USB-SATA-Konvertern leider noch nicht

> herumgefummelt, deshalb kann ich da leider überhaupt keine
> Wahrscheinlichkeit für die Ursache eines solchen Problems angeben. Was ich
> aber sicher kann, ist, die Aussage machen, daß die von mir dargestellte

> Variante kein Fehler des Konverters ist.

Ich dagegen bin mir sicher, dass die von Dir dargestellte Variante
fuer Linux nicht zutrifft, weil es im Code einfach nicht so vorgesehen
ist. (Fuer Windows mag es zutreffen, das kann man nur mit groesserem
Aufwand kontrollieren. Aber bei Windows wundert es micht auch nicht).

Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als READ/WRITE(10)
weitergibt. Weil halt der Puffer zu klein ist. Oder warum auch immer.

Und jetzt erklaere mir bitte mal, was das OS in diesem Fall tun sollte,
wenn die Bridge ihn anluegt und den 64-Bit-Befehl ohne Fehler akzeptiert,
aber ihn nur als 32-Bit weiterleitet.

Jetzt klarer?

- Dirk

[Dirk Thierbach]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Eigentlich würde ich vom OS erwarten, dass es bemerkt, dass die Bridge
>>> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
>>> oder nur als 2-TB-Platte erkennt. Wobei ich mir für beide
>>> Möglichkeiten Szenarien vorstellen kann, in denen das Verhalten
>>> ungeschickt ist.
>>
>>> Einfach irgendwas erkennen und dann Daten schreddern finde ich nicht
>>> akzeptabel.

>>Code fuer einen Test schreiben, einen Patch machen und einschicken.

> Für Windows?

Ich dachte, Du redest von Linux. Wie im Gruppennamen. Schliesslich willst
Du die Platte doch unter Linux verwenden. Oder?

Fuer Windows wundert es mich nicht, wenn es Mist baut. Halt nicht
verwenden. :-)

- Dirk

[Martin Schoenbeck]

Hallo Dirk,

Dirk Thierbach schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>> Liest Du eigentlich, worauf Du antwortest?
>
> Ja. Hier noch mal die Stelle:
>

>: Das mu� nicht sein. Wenn die Brigde nur Befehle mit 32-Bit-Sektornummern
>: unterst�tzt, dann ist das kein Fehler des Adapter, falls dann jemand
>: 512-Byte-Sektoren oberhalb 2 TiB lesen will und die n�tigen Bits nicht in
>: das Feld f�r die Sektornummer reinkriegt.

>
> Dieser Fall liegt nicht vor, da der Linux-Kernel (sd.c) *immer* ein
> READ/WRITE(16) (64 bit) erzwingt, wenn die Blocknummer zu gross fuer
> READ/WRITE(10) ist. (Zeile 1014 bei 3.7.1 sowohl fuer READ wie WRITE).

Ach. Blo� bl�d, da� der Linux-Kernel wenig dran tun kann, wenn Windows Mist
macht. Der Linux-Kernel hat aber offenbar auch nur mit 32 Bit gearbeitet,
sonst w�re er vermutlich nicht auf 801 GB gekommen. Nur ging es hier gar
nicht um den.

>> Ich habe in den Bits von USB-SATA-Konvertern leider noch nicht

>> herumgefummelt, deshalb kann ich da leider �berhaupt keine

>> Wahrscheinlichkeit f�r die Ursache eines solchen Problems angeben. Was ich
>> aber sicher kann, ist, die Aussage machen, da� die von mir dargestellte

>> Variante kein Fehler des Konverters ist.
>
> Ich dagegen bin mir sicher, dass die von Dir dargestellte Variante
> fuer Linux nicht zutrifft, weil es im Code einfach nicht so vorgesehen
> ist.

Nee, nat�rlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
antwortest. Linux hat die Platte schlicht mit einer falschen Gr��e erkannt.
Das kann am Konverter gelegen haben, mu� aber ebenfalls nicht. Wenn der nur
32-Bit-Zugriffe unterst�tzt, kann er eben keine gr��eren Platten melden.

> (Fuer Windows mag es zutreffen, das kann man nur mit groesserem
> Aufwand kontrollieren. Aber bei Windows wundert es micht auch nicht).

Du bist also doch meiner Meinung, da� es nicht unbedingt ein Fehler des
Konverters sein mu�? Na also.

> Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
> ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als READ/WRITE(10)
> weitergibt. Weil halt der Puffer zu klein ist. Oder warum auch immer.

Das wiederum halte ich f�r einigerma�en ausgeschlossen. Wohin soll sie den
denn weitergeben?

> Und jetzt erklaere mir bitte mal, was das OS in diesem Fall tun sollte,
> wenn die Bridge ihn anluegt und den 64-Bit-Befehl ohne Fehler akzeptiert,
> aber ihn nur als 32-Bit weiterleitet.

Wenn. Wie kommst Du auf die Idee, da� da 64-Bit-Befehle verwendet werden?
Windows m��te das nat�rlich und ansonsten den Betrieb ablehnen, weil
Windows die Gr��e korrekt erkannt zu haben glaubte. Nachdem Linux die Gr��e
aber nur mit 801 GB erkannt hat, gibt es doch gar keinen Anla� auf 64 Bit
zu bestehen.

> Jetzt klarer?

Bei mir gab es keinerlei Unklarheiten. Und bei Dir war vermutlich einfach
nur der "Linux -> Fehler -> kann gar nicht sein"-Reflex aktiv, obwohl es
gar nicht um Linux ging.

[Dirk Thierbach]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
> Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
> ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als READ/WRITE(10)
> weitergibt. Weil halt der Puffer zu klein ist. Oder warum auch immer.

Nachtrag: Und in der umgekehrten Richtung scheint es ja definitiv
Probleme zu geben, weil Linux offenbar das Ergebnis eines
READ_CAPACITY(16) auf 32-Bit abgeschnitten bekommt, vermutlich
sogar als Antwort auf einen READ_CAPACITY(10), statt einen
0xffffffff-Overflow wie in der Spec vorgesehen.

Marc kann ja mal spasseshalber (wenn er will) beide Kommandos mit den
sg3-tools ueber die Bridge schicken, und sich das Ergebnis anschauen.

- Dirk

[Dirk Thierbach]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
> Ach. Bloß blöd, daß der Linux-Kernel wenig dran tun kann, wenn Windows Mist

> macht. Der Linux-Kernel hat aber offenbar auch nur mit 32 Bit gearbeitet,

> sonst wäre er vermutlich nicht auf 801 GB gekommen.

Siehe anderes Posting.

> Nee, natürlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
> antwortest. Linux hat die Platte schlicht mit einer falschen Größe erkannt.
> Das kann am Konverter gelegen haben, muß aber ebenfalls nicht.

Woran sollte es sonst gelegen haben? Direkt an SATA klappt es ja.

> Wenn der nur 32-Bit-Zugriffe unterstützt, kann er eben keine
> größeren Platten melden.

Huh? Wie stellst Du Dir das konkret vor?

>> Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
>> ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als READ/WRITE(10)
>> weitergibt. Weil halt der Puffer zu klein ist. Oder warum auch immer.

> Das wiederum halte ich für einigermaßen ausgeschlossen. Wohin soll sie den
> denn weitergeben?

Na an die Festplatte ueber SATA. Bridge liest Befehl von
SCSI-ueber-USB aka USB-STORAGE, verarbeitet es, spuckt es ueber SATA
wieder aus. Die Verarbeitung findet offenbar statt, sonst gaebe es gar
keine Probleme, denn bei direktem Anschluss geht es ja. Und irgendwo
in der Verarbeitung scheint ein Wurm zu sein.

>> Und jetzt erklaere mir bitte mal, was das OS in diesem Fall tun sollte,
>> wenn die Bridge ihn anluegt und den 64-Bit-Befehl ohne Fehler akzeptiert,
>> aber ihn nur als 32-Bit weiterleitet.

> Wenn. Wie kommst Du auf die Idee, daß da 64-Bit-Befehle verwendet werden?
> Windows müßte das natürlich und ansonsten den Betrieb ablehnen, weil
> Windows die Größe korrekt erkannt zu haben glaubte.

Richtig.

> Nachdem Linux die Größe aber nur mit 801 GB erkannt hat, gibt es
> doch gar keinen Anlaß auf 64 Bit zu bestehen.

Aber Windows hat die korrekte Groesse erkannt, wenn ich mich nicht
verlesen habe. Weshalb es Marc ja unter Windows probiert hat,
was prompt schiefgegangen ist. Eben z.B. weil die Bridge
die 64-Bit-Befehle zwar akzeptiert, aber nicht korrekt weitergeleitet
hat.

> Bei mir gab es keinerlei Unklarheiten.

Siehe oben.

> Und bei Dir war vermutlich einfach nur der "Linux -> Fehler -> kann
> gar nicht sein"-Reflex aktiv,

Dass ich in der Tat gedacht habe, dass es um Linux ging, habe ich ja
schon gesagt. Ich dachte, Marc bezog sich darauf, dass er unter Linux
dann wenigstens eine 2TB-Platte haben wollte, auch wenn die Bridge
kaputt ist, ohne dass im das OS die Daten schreddert. M.a.W., der
Linux-Kernel muesste erkennen, dass die kaputte Bridge dranhaengt,
das weitere Problem beim Lesen der korrekten Groesse umgehen
und dann die Groesse kuenstlich auf 2TB limitieren. Denn sonst wuerden
die Daten geschreddert, was fuer ein OS eben nicht zumutbar ist.

Machbar, aber Aufwand.

> obwohl es gar nicht um Linux ging.

Entschuldige bitte.

- Dirk

[Helmut Hullen]

Hallo, Dirk,

Du meintest am 09.04.13:

>> Sehe ich genauso. Ich wollte nur darauf hinweisen, da� das dann kein
>> Fehler des Ger�ts ist. Sondern eben des BS.

> Das BS kann in der Regel nichts dafuer, wenn eine
> Hardware-Zwischenschicht behaupet "ich kann das uebertragen", bei der
> Uebertragung dann aber nicht alles uebertraegt.

Mag sein. Scheint f�r die Hardware, die Marc benutzt hat, nicht
hzuzutreffen:

----------------- Zitat ein -----------------

ich habe hier ein USB2-SATA-Geh�use mit Initio-Bridge:

|Bus 001 Device 084: ID 13fd:1340 Initio Corporation Hi-Speed USB to SATA Bridge

Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB
erkannt:

----------------- Zitat aus -----------------

So kenne ich das von einigen meiner SATA-USB-Adapter: sie liefern
anscheinend die Daten an Linux, mit deren Hilfe Linux dann erkennt, dass
(bei einer 3-TByte-Platte) nur 801 GByte benutzt werden k�nnen.

Windows (jedenfalls Windows XP) mault da nicht herum, d�rfte aber (wie
Marc gepr�ft hat) auch keine 3 TByte "sauber" benutzen k�nnen.

[Helmut Hullen]

Hallo, Martin,

Du meintest am 09.04.13:

[...]

>> Ich dagegen bin mir sicher, dass die von Dir dargestellte Variante
>> fuer Linux nicht zutrifft, weil es im Code einfach nicht so
>> vorgesehen ist.

> Nee, nat�rlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
> antwortest. Linux hat die Platte schlicht mit einer falschen Gr��e
> erkannt. Das kann am Konverter gelegen haben, mu� aber ebenfalls
> nicht. Wenn der nur 32-Bit-Zugriffe unterst�tzt, kann er eben keine
> gr��eren Platten melden.

Im speziellen Fall (ID 13fd:1340) gilt aber, dass dieses "Ger�t" nur
max. 2 TiByte erkennen kann (also "modulo 2 TiByte" arbeitet).

[Marc Haber]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>Ich dachte, Du redest von Linux. Wie im Gruppennamen.

Manchmal hilft es die Threads zu lesen in denen man schreibt.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Im speziellen Fall (ID 13fd:1340) gilt aber, dass dieses "Gerät" nur

>max. 2 TiByte erkennen kann (also "modulo 2 TiByte" arbeitet).

"Maximal 2 TiByte erkennen" ist etwas deutlich anderes als "modulo 2
TiByte arbeiten". Ersteres ist verständlich und akzeptabel, zweiteres
killt im Zweifel Daten.

[Martin Schoenbeck]

Hallo Dirk,

Dirk Thierbach schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>> Ach. Blo� bl�d, da� der Linux-Kernel wenig dran tun kann, wenn Windows Mist

>> macht. Der Linux-Kernel hat aber offenbar auch nur mit 32 Bit gearbeitet,

>> sonst w�re er vermutlich nicht auf 801 GB gekommen.
>
> Siehe anderes Posting.
>
>> Nee, nat�rlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
>> antwortest. Linux hat die Platte schlicht mit einer falschen Gr��e erkannt.
>> Das kann am Konverter gelegen haben, mu� aber ebenfalls nicht.

>
> Woran sollte es sonst gelegen haben? Direkt an SATA klappt es ja.

Eine beeindruckende Analyse.

>> Wenn der nur 32-Bit-Zugriffe unterst�tzt, kann er eben keine

>> gr��eren Platten melden.

>
> Huh? Wie stellst Du Dir das konkret vor?

Wenn er nur Read Capacity (10) unterst�tzt, ist mit 2 TiB eben Ende.
Jedenfalls bei 512-Byte-Sektoren. In fr�heren Versionen gab's �brigens noch
keine Anforderung, 32 Einsen zu melden, wenn das Ger�t die m�gliche
Kapazit�t �berschreitet. Ist zwar eigentlich auch die logische L�sung, aber
zumindest macht die Meldung einer zu kleinen Kapazit�t ja erstmal nichts
kaputt.

>
>>> Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
>>> ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als READ/WRITE(10)
>>> weitergibt. Weil halt der Puffer zu klein ist. Oder warum auch immer.
>

>> Das wiederum halte ich f�r einigerma�en ausgeschlossen. Wohin soll sie den

>> denn weitergeben?
>
> Na an die Festplatte ueber SATA. Bridge liest Befehl von
> SCSI-ueber-USB aka USB-STORAGE, verarbeitet es, spuckt es ueber SATA
> wieder aus. Die Verarbeitung findet offenbar statt, sonst gaebe es gar
> keine Probleme, denn bei direktem Anschluss geht es ja. Und irgendwo
> in der Verarbeitung scheint ein Wurm zu sein.

In der Verarbeitung mu� nur dann ein Wurm sein, wenn das Ding �berhaupt
READ/WRITE (16) unterst�tzt. Ansonsten liegt der Wurm bei Windows. Und wenn
es READ/WRITE (16) unterst�tzt und die Platte auch mit packet-commands
anspricht, m��te jemand schon mit dem Klammerbeutel gepudert sein, an den
Kommandos �berhaupt rumzubasteln, statt die stumpf durchzureichen. Wenn es
READ/WRITE (16) unterst�tzt und non-packet-commands nutzt, ist die Chance
nat�rlich gr��er, aber warum sollte man dann �berhaupt (16)-Kommandos
implementieren, wenn man sich auf die Feldgr��en der (10)-Kommandos
beschr�nken will.

>>> Und jetzt erklaere mir bitte mal, was das OS in diesem Fall tun sollte,
>>> wenn die Bridge ihn anluegt und den 64-Bit-Befehl ohne Fehler akzeptiert,
>>> aber ihn nur als 32-Bit weiterleitet.
>

>> Wenn. Wie kommst Du auf die Idee, da� da 64-Bit-Befehle verwendet werden?

>> Windows m��te das nat�rlich und ansonsten den Betrieb ablehnen, weil
>> Windows die Gr��e korrekt erkannt zu haben glaubte.
>
> Richtig.
>
>> Nachdem Linux die Gr��e aber nur mit 801 GB erkannt hat, gibt es
>> doch gar keinen Anla� auf 64 Bit zu bestehen.

>
> Aber Windows hat die korrekte Groesse erkannt, wenn ich mich nicht
> verlesen habe. Weshalb es Marc ja unter Windows probiert hat,
> was prompt schiefgegangen ist. Eben z.B. weil die Bridge
> die 64-Bit-Befehle zwar akzeptiert, aber nicht korrekt weitergeleitet
> hat.

Ich tippe eher, da� Marc die Platte irgendwo per SATA mit Partitionen
versehen hat und Windows gesehen hat, da� diese 3 TB umfassen. Und sich gar
nicht um irgendwelche anderen Angaben geschert hat. Aber wer wei� das
schon.

[Marc Haber]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>Ich tippe eher, daß Marc die Platte irgendwo per SATA mit Partitionen
>versehen hat und Windows gesehen hat, daß diese 3 TB umfassen.

Interessante Theorie. Ich liefere in den nächsten Tagen die
Bestätigung.

[Dirk Thierbach]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>>> Nee, natürlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
>>> antwortest. Linux hat die Platte schlicht mit einer falschen Größe erkannt.
>>> Das kann am Konverter gelegen haben, muß aber ebenfalls nicht.

>> Woran sollte es sonst gelegen haben? Direkt an SATA klappt es ja.

> Eine beeindruckende Analyse.

An der was genau falsch ist?

>>> Wenn der nur 32-Bit-Zugriffe unterstützt, kann er eben keine

>>> größeren Platten melden.

>> Huh? Wie stellst Du Dir das konkret vor?

> Wenn er nur Read Capacity (10) unterstützt, ist mit 2 TiB eben Ende.

Dann kann man ja einfach READ_CAPACITY(16) nehmen. Wenn die Bridge,
wie Du vermutest, die Kommandos einfach durchreicht, sollte es ja
gehen.

> Jedenfalls bei 512-Byte-Sektoren. In früheren Versionen gab's übrigens noch
> keine Anforderung, 32 Einsen zu melden, wenn das Gerät die mögliche
> Kapazität überschreitet. Ist zwar eigentlich auch die logische Lösung, aber
> zumindest macht die Meldung einer zu kleinen Kapazität ja erstmal nichts
> kaputt.

Es fuehrt halt dazu, dass der Linux-Kernel evtl. READ_CAPACITY(16) gar
nicht erst probiert. Die Bedingungen dazu sind etwas komplex, die
habe ich mir nicht genau angeschaut.

> In der Verarbeitung muß nur dann ein Wurm sein, wenn das Ding überhaupt
> READ/WRITE (16) unterstützt.

Na ja. Die Platte muss es unterstuetzen. Wenn, wie Du behauptest, die
Bridge die Kommandos einfach durchreicht, muss es in diesem Fall auch
ueber USB gehen. Weil dann die Bridge keinen Einfluss darauf hat,
welche Kommandos "unterstuetzt" werden. Tut es aber offenbar nicht.
Also bleibt nur uebrig, dass die Bridge die Kommandos nicht durchreicht,
sondern sie in irgendeiner Form verarbeitet.

> Ansonsten liegt der Wurm bei Windows. Und wenn es READ/WRITE (16)

> unterstützt und die Platte auch mit packet-commands anspricht, müßte

> jemand schon mit dem Klammerbeutel gepudert sein, an den Kommandos

> überhaupt rumzubasteln, statt die stumpf durchzureichen.

Verstehen tu ich's auch nicht, aber diese Erklaerung leuchtet mir
eher ein, als dass die Windows-Programmierer zu bloed sind, das richtige
Kommando zu benutzen.

> Ich tippe eher, daß Marc die Platte irgendwo per SATA mit Partitionen
> versehen hat und Windows gesehen hat, daß diese 3 TB umfassen. Und sich gar
> nicht um irgendwelche anderen Angaben geschert hat. Aber wer weiß das
> schon.

Das ist natuerlich moeglich. Man kann es ja einfach testen; man
muss der Bridge nur die entsprechenden SCSI-Befehle schicken. Genauso
kann man testen, ob es READ/WRITE(16) unterstuetzt.

Man muss also gar nicht raten, man kann es herausfinden.

- Dirk

[Henning Paul]

Dirk Thierbach schrieb:

> Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
>> Dagegen kann ich mir die Variante vorstellen, dass die Bridge zwar
>> ein READ/WRITE(16) ohne Fehler akzeptiert, aber nur als
>> READ/WRITE(10) weitergibt. Weil halt der Puffer zu klein ist. Oder
>> warum auch immer.
>
> Nachtrag: Und in der umgekehrten Richtung scheint es ja definitiv
> Probleme zu geben, weil Linux offenbar das Ergebnis eines
> READ_CAPACITY(16) auf 32-Bit abgeschnitten bekommt, vermutlich
> sogar als Antwort auf einen READ_CAPACITY(10), statt einen
> 0xffffffff-Overflow wie in der Spec vorgesehen.

Ich vermute stark, dass bereits die Firmware des USB-SATA-Wandlers die
oberen Bits abschneidet, und auf READ_CAPACITY(16) und READ_CAPACITY(10)
grundsätzlich mit dem selben Wert antwortet.

> Marc kann ja mal spasseshalber (wenn er will) beide Kommandos mit den
> sg3-tools ueber die Bridge schicken, und sich das Ergebnis anschauen.

Bei der wie erwähnt ebenfalls fehlerhaft funktionierenden "152d:2338
JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed
USB to SATA & PATA Combo Bridge" schaut es so aus:

root@oslo [~] # sg_readcap /dev/sdg
Read Capacity results:
Last logical block address=1565565871 (0x5d50a3af), Number of
blocks=1565565872
Logical block length=512 bytes
Hence:
Device size: 801569726464 bytes, 764436.5 MiB, 801.57 GB
root@oslo [~] # sg_readcap --16 /dev/sdg
READ CAPACITY (16) not supported

READ CAPACITY (16) wird also überhaupt nicht unterstützt.
Nichtsdestotrotz meldet smartctl natürlich die volle Kapazität, weil es
die Platte direkt befragt, also wundert es mich nicht, dass Windows 3TB
meldet.

Eine "152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
JM20329 SATA Bridge" (ICY BOX IB-390StUS-B) geht:

root@oslo [~] # sg_readcap /dev/sdg
READ CAPACITY (10) indicates device capacity too large
now trying 16 byte cdb variant
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

Gruß
Henning

[Marc Haber]

Henning Paul <henni...@gmx.de> wrote:
>Bei der wie erwähnt ebenfalls fehlerhaft funktionierenden "152d:2338
>JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed
>USB to SATA & PATA Combo Bridge" schaut es so aus:
>
>root@oslo [~] # sg_readcap /dev/sdg
>Read Capacity results:
> Last logical block address=1565565871 (0x5d50a3af), Number of
>blocks=1565565872
> Logical block length=512 bytes
>Hence:
> Device size: 801569726464 bytes, 764436.5 MiB, 801.57 GB
>root@oslo [~] # sg_readcap --16 /dev/sdg
>READ CAPACITY (16) not supported
>
>READ CAPACITY (16) wird also überhaupt nicht unterstützt.

Genauso ist es bei dem Gehäuse mit dem Initio-Chipsatz. Die Zahlen
stimmen exakt überein.

>Nichtsdestotrotz meldet smartctl natürlich die volle Kapazität, weil es
>die Platte direkt befragt, also wundert es mich nicht, dass Windows 3TB
>meldet.

Windows geht offensichlich nach der Partitionstabelle vor.

Eine 2.5-TB-Partition auf der GPT-partitionierten 3-TB-Platte wird von
Windows, wenn das erste Gigabyte der Platte vorher ausgenullt wurde,
als 2,3-T(i?)B erkannt, und Windows legt auch happily darauf dann ein
exfat-Dateisystem an. Ich habe nicht probiert, was passiert, wenn ich
das vollschreibe, aber ich vermute das Verhalten wird ähnlich sein wie
bei der 3-TB-Partition.

Im nächsten Versuch wird die Platte unter Linux erneut genullt, eine
2.5-TB-Partition angelegt und mkfs.vfat ausgeführt. Das entstehende
Dateisystem, unter Linux eingehängt, wird von Linux selbst falsch mit
Größe 281 GB erkannt. Hier hätte ich erwartet, dass entweder mkfs.vfat
sich beklagt, dass es kein so großes Dateisystem anlegen kann (vfat
hat eine 2-TB-Maximalgröße, oder?), oder dass Linux beim Einhängen
mault. Aber eine falsche Größe erkennen ist irgendwie doof.

Diese so partitionierte und formatierte Platte wird von Windows in der
Datenträgerverwaltung mit 1,9 TiB und ein paar zerquetschte erkannt.
Sprich, Windows geht im ersten Schritt nach der Partitionstabelle, im
zweiten Schritt nach dem Dateisystem und nimmt dann nach 2 TiB
kommentarlos einen Wraparound inkauf.

Interessantes Verhalten.

[Martin Schoenbeck]

> Bei eine Art �berlauf geschieht typischerweise ein Wrap-around oder es
> tritt eine S�ttigung (der Wert bleibt auf einen Maximal- bzw.
> Minimalwert stehen) auf.

War diese Aussage in irgendeiner Weise als Antwort auf meine Frage gedacht?
Wenn ja, dann verstehe ich nicht, wie sie meine Frage beantworten soll.
Wenn Du einfach nur was sagen wolltest, dann kann ich best�tigen, da� Du
das richtig beschrieben hast.

[Martin Schoenbeck]

> Offensichtlich. Henning Paul geht in Artikel
> <news:4544149.F...@oslo.comm.uni-bremen.de> genauer auf das Ph�nomen
> Wrap-Around (Abschneiden der h�herwertigen Bits per modulo-2^n-Rechnung) ein.

Was passiert, wenn man die oberen Bits abschneidet, ist einigerma�en banal.
Deshalb ja mein Erstaunen, da� Du das als Antwort auf meine Frage gesehen
hast.

> Ich bem�he mich, bei meinen Antworten den Kontext mitzuf�hren. Falls
> Du Dich auf etwas anderes beziehen solltest (z.B. irgendein
> "Szenario"), ist das Dein Problem.

Das, worauf ich mich bezog, war das Posting, auf das Marc geantwortet hat.
Wenn Dir das schon zu abgedreht ist, dann wird's schwierig mit der
Diskussion.

> Vermutlich bist Du im
> Diskussionsstrang verrutscht.

Definitiv nicht.

> Mir geht es um Marcs Anforderung an ein
> OS, welche nach meinem Daf�rhalten schwierig zu erf�llen ist.

die ist schwierig zu erf�llen, wenn die Hardware l�gt. Damit Windows den
beschriebenen Schrott macht, ist es aber �berhaupt nicht n�tig, da� die
Hardware l�gt. Marc hat das ja inzwischen verifiziert. Deshalb wollte ich
von Dir wissen, warum Du ein L�gen der Hardware f�r die beschriebenen
Probleme zwingend voraussetzen wolltest. Falls jetzt immer noch nicht
r�bergekommen ist, was ich wollte, geb ich es auf.

[Martin Schoenbeck]

Hallo Dirk,

Dirk Thierbach schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>>>> Nee, nat�rlich nicht. Deshalb fragte ich, ob Du liest, worauf Du
>>>> antwortest. Linux hat die Platte schlicht mit einer falschen Gr��e erkannt.
>>>> Das kann am Konverter gelegen haben, mu� aber ebenfalls nicht.

>
>>> Woran sollte es sonst gelegen haben? Direkt an SATA klappt es ja.
>
>> Eine beeindruckende Analyse.
>
> An der was genau falsch ist?
>

>>>> Wenn der nur 32-Bit-Zugriffe unterst�tzt, kann er eben keine

>>>> gr��eren Platten melden.

>
>>> Huh? Wie stellst Du Dir das konkret vor?
>

>> Wenn er nur Read Capacity (10) unterst�tzt, ist mit 2 TiB eben Ende.

>
> Dann kann man ja einfach READ_CAPACITY(16) nehmen. Wenn die Bridge,
> wie Du vermutest, die Kommandos einfach durchreicht, sollte es ja
> gehen.

Ich habe keineswegs vermutet, da� die Bridge die Kommandos einfach
durchreicht. Vielmehr sollte mich das wundern. Schlie�lich ist keine Platte
gezwungen, �berhaupt ATAPI-Kommandos zu implementieren. Ich wei� nicht, ob
die das inzwischen quasi standardm��ig machen. Ich hatte im Kopf, da�
Platten das nicht einmal sollen, aber das konnte ich in den Standards nicht
wiederfinden. Aber sie m�ssen es jedenfalls nicht. Also sollte der Adapter
wohl die Kommandos interpretieren und in non-packet-commands umsetzen. Oder
er mu� unterscheiden, ob die Platte packet-commands kann und dann anders
agieren. Aber wozu sollte er.

Nur _wenn_ er die Platte mit packet-commands anspricht, _dann_ w�re es
ziemlich bl�dsinnig, (16)-Kommandos entgegenzunehmen und sie dann nicht
einfach weiterzuleiten oder gar (wie Du es vermutetest) sie m�hsam in ein
(10)-Kommando umzusetzen. Wo man ja vorher wei�, da� das nicht geht.

>> Jedenfalls bei 512-Byte-Sektoren. In fr�heren Versionen gab's �brigens noch
>> keine Anforderung, 32 Einsen zu melden, wenn das Ger�t die m�gliche

>> Kapazit�t �berschreitet. Ist zwar eigentlich auch die logische L�sung, aber
>> zumindest macht die Meldung einer zu kleinen Kapazit�t ja erstmal nichts

>> kaputt.
>
> Es fuehrt halt dazu, dass der Linux-Kernel evtl. READ_CAPACITY(16) gar
> nicht erst probiert. Die Bedingungen dazu sind etwas komplex, die
> habe ich mir nicht genau angeschaut.

Wenn die Bridge READ CAPACITY (16) unterst�tzte, dann k�nnte man ihr sicher
vorwerfen, da� sie beim (10)er nicht mit ffen reagiert. Denn da steht es ja
im Standard. So hat man einfach das Problem, da� man als Benutzer wissen
mu�, da� das Ding nicht f�r mehr als zwei TB taugt.

>> In der Verarbeitung mu� nur dann ein Wurm sein, wenn das Ding �berhaupt
>> READ/WRITE (16) unterst�tzt.
>

> Na ja. Die Platte muss es unterstuetzen.

Das mu� sie nicht.

> Wenn, wie Du behauptest, die
> Bridge die Kommandos einfach durchreicht, muss es in diesem Fall auch
> ueber USB gehen.

Wenn ich das denn behauptet h�tte.

> Weil dann die Bridge keinen Einfluss darauf hat,
> welche Kommandos "unterstuetzt" werden. Tut es aber offenbar nicht.

Sie mu� die Kommandos schon auch selbst kennen, weil sie sonst nicht wei�,
was sie dann an weiteren Daten herumschubsen mu�.

> Also bleibt nur uebrig, dass die Bridge die Kommandos nicht durchreicht,
> sondern sie in irgendeiner Form verarbeitet.

Nat�rlich. Aber kaum, indem sie sie in andere SCSI-Kommandos umsetzt.

>> Ansonsten liegt der Wurm bei Windows. Und wenn es READ/WRITE (16)

>> unterst�tzt und die Platte auch mit packet-commands anspricht, m��te

>> jemand schon mit dem Klammerbeutel gepudert sein, an den Kommandos

>> �berhaupt rumzubasteln, statt die stumpf durchzureichen.

>
> Verstehen tu ich's auch nicht, aber diese Erklaerung leuchtet mir
> eher ein, als dass die Windows-Programmierer zu bloed sind, das richtige
> Kommando zu benutzen.

Und dann festzustellen, da� die Bridge ein solches nicht kennt und dann
gef�lligst die Finger von der Platte zu lassen.

>> Ich tippe eher, da� Marc die Platte irgendwo per SATA mit Partitionen
>> versehen hat und Windows gesehen hat, da� diese 3 TB umfassen. Und sich gar
>> nicht um irgendwelche anderen Angaben geschert hat. Aber wer wei� das

>> schon.
>
> Das ist natuerlich moeglich. Man kann es ja einfach testen; man
> muss der Bridge nur die entsprechenden SCSI-Befehle schicken. Genauso
> kann man testen, ob es READ/WRITE(16) unterstuetzt.
>
> Man muss also gar nicht raten, man kann es herausfinden.

Ich mu� schon raten. Marc hat's ja inzwischen best�tigt.

[Martin Schoenbeck]

Hallo Heiko,

Heiko Schlenker schrieb:

> * Martin Schoenbeck <ms.usene...@schoenbeck.de> schrieb:
>>>>>>>> Heiko Schlenker schrieb:

>>>>>>>>> * Marc Haber <mh+usene...@zugschl.us> schrieb:
>>>>>>>>>> Eigentlich w�rde ich vom OS erwarten, dass es bemerkt, dass die Bridge
>>>>>>>>>> keine 64bit-Sektornummern kann und dann die Platte entweder ablehnt
>>>>>>>>>> oder nur als 2-TB-Platte erkennt.
>>>>>>>>>
>>>>>>>>> Ein OS hat eigentlich keine Chance, wenn die Hardware l�gt.

> [...]

>> Deshalb wollte ich von Dir wissen, warum Du ein L�gen der Hardware f�r
>> die beschriebenen Probleme zwingend voraussetzen wolltest.

> ^^^^^^^^^^^^^^^^^^^^^
> N�, es ist keine notwendige Bedingung formuliert worden, sondern eine
> hinreichende.

Also wieder nur eine Banalit�t.

Ok.

[Martin Schoenbeck]

Hallo Heiko,

Heiko Schlenker schrieb:

> Was soll das? Ich bin erstens mit keinem Wort auf Dein "Szenario"
> eingegangen, noch habe ich zweitens das von Dir Unterstellte
> geschrieben. Deine Freizeit sollte f�r solch eine alberne
> Strohmann-Argumentation zu schade sein.

Jetzt komm mal wieder runter. Du hast Marc auf seine Aussage hin, er
erwarte, da� ein BS merken m�sse, wenn die Bridge keine 64Bit-Sektornummern
anbiete, geschrieben, da� das BS keine Chance habe, wenn die Hardware l�ge.
Da Marc seine Aussage direkt auf mein Szenario bezog, bei der die Hardware
eben nicht l�gen mu�te, sondern schlicht nur keine 64Bit-Sektornummern
erm�glichte, war schon Deine erstes Posting entweder nur ein "ich will auch
mal was sagen"-Posting, weil es mit Marcs Aussage nichts zu tun hatte, oder
es bezog sich eben doch auf Marcs Aussage und damit auf mein Szenario.

[Marc Haber]

Henning Paul <henni...@gmx.de> wrote:
>Eine "152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
>JM20329 SATA Bridge" (ICY BOX IB-390StUS-B) geht:
>
>root@oslo [~] # sg_readcap /dev/sdg
>READ CAPACITY (10) indicates device capacity too large
> now trying 16 byte cdb variant
>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

Ich hab hier einen "174c:5106 ASMedia Technology Inc. Transcend
StoreJet 25M3". Das ist eine Icy Box IB-366StU3-B:

|$ sudo sg_readcap /dev/sdd
|[sudo] password for mh:

|READ CAPACITY (10) indicates device capacity too large
| now trying 16 byte cdb variant
|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

|$

Auch hier stimmen die Zahlen wieder exakt überein.

Interessant finde ich, dass lsusb das Icy Box Gehäuse als Transcend
StoreJet identifiziert. Ob da absichtlich eine Produktbezeichnung, die
über den Chipsatz hinausgeht, in die usb.ids hinengerutscht ist? Die
usb.ids kennt für Vendor 174c (ASMedia) überhaupt nur eine Product ID,
und das ist die hier beobachtete 5106.

[Marc Haber]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>Wenn er nur Read Capacity (10) unterstützt, ist mit 2 TiB eben Ende.

>Jedenfalls bei 512-Byte-Sektoren. In früheren Versionen gab's übrigens noch
>keine Anforderung, 32 Einsen zu melden, wenn das Gerät die mögliche
>Kapazität überschreitet. Ist zwar eigentlich auch die logische Lösung, aber
>zumindest macht die Meldung einer zu kleinen Kapazität ja erstmal nichts
>kaputt.

Kaputt macht es erst etwas, wenn der Host dann versucht, das zu klein
gemeldete Medium zu benutzen. Es gibt durchaus
Verwaltungsinformationen, die an das Ende des Devices geschrieben
werden, und das landet dann halt mitten in den Daten.

>> Na an die Festplatte ueber SATA. Bridge liest Befehl von
>> SCSI-ueber-USB aka USB-STORAGE, verarbeitet es, spuckt es ueber SATA
>> wieder aus. Die Verarbeitung findet offenbar statt, sonst gaebe es gar
>> keine Probleme, denn bei direktem Anschluss geht es ja. Und irgendwo
>> in der Verarbeitung scheint ein Wurm zu sein.
>

>In der Verarbeitung muß nur dann ein Wurm sein, wenn das Ding überhaupt
>READ/WRITE (16) unterstützt. Ansonsten liegt der Wurm bei Windows. Und wenn
>es READ/WRITE (16) unterstützt und die Platte auch mit packet-commands
>anspricht, müßte jemand schon mit dem Klammerbeutel gepudert sein, an den
>Kommandos überhaupt rumzubasteln, statt die stumpf durchzureichen. Wenn es
>READ/WRITE (16) unterstützt und non-packet-commands nutzt, ist die Chance
>natürlich größer, aber warum sollte man dann überhaupt (16)-Kommandos
>implementieren, wenn man sich auf die Feldgrößen der (10)-Kommandos
>beschränken will

Das "alte" Gehäuse unterstützt die (16)-Kommandos nicht. Dass Windows
trotzdem fleißig versucht, eine > 2 TiB große Partition mit
(10)-Kommandos schreibend anzusprechen, ist IMO kaputt und gefährlich.
Das gehört im OS unterbunden.

>> Aber Windows hat die korrekte Groesse erkannt, wenn ich mich nicht
>> verlesen habe. Weshalb es Marc ja unter Windows probiert hat,
>> was prompt schiefgegangen ist. Eben z.B. weil die Bridge
>> die 64-Bit-Befehle zwar akzeptiert, aber nicht korrekt weitergeleitet
>> hat.
>

>Ich tippe eher, daß Marc die Platte irgendwo per SATA mit Partitionen
>versehen hat und Windows gesehen hat, daß diese 3 TB umfassen. Und sich gar

>nicht um irgendwelche anderen Angaben geschert hat.

Ich halte Deine Diagnose für korrekt.

[Marc Haber]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:

>Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>> Jedenfalls bei 512-Byte-Sektoren. In früheren Versionen gab's übrigens noch
>> keine Anforderung, 32 Einsen zu melden, wenn das Gerät die mögliche
>> Kapazität überschreitet. Ist zwar eigentlich auch die logische Lösung, aber
>> zumindest macht die Meldung einer zu kleinen Kapazität ja erstmal nichts
>> kaputt.
>
>Es fuehrt halt dazu, dass der Linux-Kernel evtl. READ_CAPACITY(16) gar
>nicht erst probiert.

So sieht das für mich aus. Hier das Syslog mit dem alten Gehäuse:
|Apr 5 22:29:26 fan kernel: [10911.140123] usb 8-5: new high-speed USB device number 4 using ehci-pci
|Apr 5 22:29:26 fan kernel: [10911.273678] usb 8-5: New USB device found, idVendor=13fd, idProduct=1340
|Apr 5 22:29:26 fan kernel: [10911.273693] usb 8-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
|Apr 5 22:29:26 fan kernel: [10911.273702] usb 8-5: Product: External
|Apr 5 22:29:26 fan kernel: [10911.273710] usb 8-5: Manufacturer: Generic
|Apr 5 22:29:26 fan kernel: [10911.273716] usb 8-5: SerialNumber: S1F0YGPT
|Apr 5 22:29:26 fan kernel: [10911.275269] scsi13 : usb-storage 8-5:1.0
|Apr 5 22:29:26 fan udevd[10857]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/pci0000:00/0000:00:13.2/usb8/8-5 8 4': No such file o
|Apr 5 22:29:27 fan kernel: [10912.272946] scsi 13:0:0:0: Direct-Access Generic External 1.04 PQ: 0 ANSI: 4
|Apr 5 22:29:27 fan kernel: [10912.273484] sd 13:0:0:0: Attached scsi generic sg5 type 0
|Apr 5 22:29:27 fan kernel: [10912.275788] sd 13:0:0:0: [sde] 1565565872 512-byte logical blocks: (801 GB/746 GiB)
|Apr 5 22:29:27 fan kernel: [10912.277051] sd 13:0:0:0: [sde] Write Protect is off
|Apr 5 22:29:27 fan kernel: [10912.277064] sd 13:0:0:0: [sde] Mode Sense: 21 00 00 00
|Apr 5 22:29:27 fan kernel: [10912.278332] sd 13:0:0:0: [sde] No Caching mode page present
|Apr 5 22:29:27 fan kernel: [10912.278346] sd 13:0:0:0: [sde] Assuming drive cache: write through
|Apr 5 22:29:27 fan kernel: [10912.283396] sd 13:0:0:0: [sde] No Caching mode page present
|Apr 5 22:29:27 fan kernel: [10912.283408] sd 13:0:0:0: [sde] Assuming drive cache: write through
|Apr 5 22:29:27 fan kernel: [10912.301432] sde: unknown partition table
|Apr 5 22:29:27 fan kernel: [10912.304797] sd 13:0:0:0: [sde] No Caching mode page present
|Apr 5 22:29:27 fan kernel: [10912.304811] sd 13:0:0:0: [sde] Assuming drive cache: write through
|Apr 5 22:29:27 fan kernel: [10912.304820] sd 13:0:0:0: [sde] Attached SCSI disk


und hier zum Vergleich das mit dem neuen Gehäuse:
|Apr 10 13:01:33 fan kernel: [ 5474.812195] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
|Apr 10 13:01:33 fan kernel: [ 5474.825017] usb 2-2: Parent hub missing LPM exit latency info. Power management will be impacted.
|Apr 10 13:01:43 fan kernel: [ 5484.806636] usb 2-2: New USB device found, idVendor=174c, idProduct=5106
|Apr 10 13:01:43 fan kernel: [ 5484.806651] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
|Apr 10 13:01:43 fan kernel: [ 5484.806661] usb 2-2: Product: AS2105
|Apr 10 13:01:43 fan kernel: [ 5484.806669] usb 2-2: Manufacturer: ASMedia
|Apr 10 13:01:44 fan kernel: [ 5485.650606] scsi11 : usb-storage 2-2:1.0
|Apr 10 13:01:44 fan udevd[8965]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/usb2/2-2 2 2': No
|Apr 10 13:01:45 fan kernel: [ 5486.648248] scsi 11:0:0:0: Direct-Access ST3000DM 001-9YN166 CC4B PQ: 0 ANSI: 5
|Apr 10 13:01:45 fan kernel: [ 5486.648814] sd 11:0:0:0: Attached scsi generic sg4 type 0
|Apr 10 13:01:45 fan kernel: [ 5486.648967] sd 11:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
|Apr 10 13:01:45 fan kernel: [ 5486.649211] sd 11:0:0:0: [sdd] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
|Apr 10 13:01:45 fan kernel: [ 5486.649712] sd 11:0:0:0: [sdd] Write Protect is off
|Apr 10 13:01:45 fan kernel: [ 5486.649731] sd 11:0:0:0: [sdd] Mode Sense: 23 00 00 00
|Apr 10 13:01:45 fan kernel: [ 5486.650196] sd 11:0:0:0: [sdd] No Caching mode page present
|Apr 10 13:01:45 fan kernel: [ 5486.650206] sd 11:0:0:0: [sdd] Assuming drive cache: write through
|Apr 10 13:01:45 fan kernel: [ 5486.650807] sd 11:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
|Apr 10 13:01:45 fan kernel: [ 5486.652099] sd 11:0:0:0: [sdd] No Caching mode page present
|Apr 10 13:01:45 fan kernel: [ 5486.652113] sd 11:0:0:0: [sdd] Assuming drive cache: write through
|Apr 10 13:01:45 fan kernel: [ 5486.694431] sdd: sdd1 sdd2
|Apr 10 13:01:45 fan kernel: [ 5486.695463] sd 11:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
|Apr 10 13:01:45 fan kernel: [ 5486.696499] sd 11:0:0:0: [sdd] No Caching mode page present
|Apr 10 13:01:45 fan kernel: [ 5486.696511] sd 11:0:0:0: [sdd] Assuming drive cache: write through
|Apr 10 13:01:45 fan kernel: [ 5486.696522] sd 11:0:0:0: [sdd] Attached SCSI disk

Ich würde das so interpretieren, als dass der Linux-Kernel die
(16)-Befehle nicht auf Verdacht nutzt, sondern dass irgendwelche
Voraussetzungen (z.B. eine "all 1" Rückmeldung auf den (10)-Befehl)
vorliegen müssen.

>Die Bedingungen dazu sind etwas komplex, die
>habe ich mir nicht genau angeschaut.

Ist es das was Du meinst?

[Martin Schoenbeck]

Hallo Marc,

Marc Haber schrieb:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>>Wenn er nur Read Capacity (10) unterst�tzt, ist mit 2 TiB eben Ende.
>>Jedenfalls bei 512-Byte-Sektoren. In fr�heren Versionen gab's �brigens noch
>>keine Anforderung, 32 Einsen zu melden, wenn das Ger�t die m�gliche

>>Kapazit�t �berschreitet. Ist zwar eigentlich auch die logische L�sung, aber
>>zumindest macht die Meldung einer zu kleinen Kapazit�t ja erstmal nichts

>>kaputt.
>
> Kaputt macht es erst etwas, wenn der Host dann versucht, das zu klein
> gemeldete Medium zu benutzen. Es gibt durchaus
> Verwaltungsinformationen, die an das Ende des Devices geschrieben
> werden, und das landet dann halt mitten in den Daten.

Einfach so unabh�ngig davon, ob eventuell eine Partition eingerichtet ist,
die bis dahin geht? F�nde ich hochgradig grenzwertig. Und sp�testens mit
der Auswertung der Partitionstabellen mu� man dann ohnehin die Pfoten von
dem Medium lassen.

>>> Na an die Festplatte ueber SATA. Bridge liest Befehl von
>>> SCSI-ueber-USB aka USB-STORAGE, verarbeitet es, spuckt es ueber SATA
>>> wieder aus. Die Verarbeitung findet offenbar statt, sonst gaebe es gar
>>> keine Probleme, denn bei direktem Anschluss geht es ja. Und irgendwo
>>> in der Verarbeitung scheint ein Wurm zu sein.
>>

>>In der Verarbeitung mu� nur dann ein Wurm sein, wenn das Ding �berhaupt
>>READ/WRITE (16) unterst�tzt. Ansonsten liegt der Wurm bei Windows. Und wenn
>>es READ/WRITE (16) unterst�tzt und die Platte auch mit packet-commands
>>anspricht, m��te jemand schon mit dem Klammerbeutel gepudert sein, an den
>>Kommandos �berhaupt rumzubasteln, statt die stumpf durchzureichen. Wenn es
>>READ/WRITE (16) unterst�tzt und non-packet-commands nutzt, ist die Chance
>>nat�rlich gr��er, aber warum sollte man dann �berhaupt (16)-Kommandos
>>implementieren, wenn man sich auf die Feldgr��en der (10)-Kommandos
>>beschr�nken will
>

> Das "alte" Geh�use unterst�tzt die (16)-Kommandos nicht. Dass Windows
> trotzdem flei�ig versucht, eine > 2 TiB gro�e Partition mit
> (10)-Kommandos schreibend anzusprechen, ist IMO kaputt und gef�hrlich.
> Das geh�rt im OS unterbunden.

Aber sowas von ACK

>
>>> Aber Windows hat die korrekte Groesse erkannt, wenn ich mich nicht
>>> verlesen habe. Weshalb es Marc ja unter Windows probiert hat,
>>> was prompt schiefgegangen ist. Eben z.B. weil die Bridge
>>> die 64-Bit-Befehle zwar akzeptiert, aber nicht korrekt weitergeleitet
>>> hat.
>>

>>Ich tippe eher, da� Marc die Platte irgendwo per SATA mit Partitionen
>>versehen hat und Windows gesehen hat, da� diese 3 TB umfassen. Und sich gar

>>nicht um irgendwelche anderen Angaben geschert hat.
>

> Ich halte Deine Diagnose f�r korrekt.

Das war ja eher ein sogenannter "educated guess". Da hat man bei Microsoft
ja oft gute Karten, wenn man eine m�glichst bescheuerte Implementation
annimmt.

[Michael Baeuerle]

Marc Haber wrote:
>
> Ich w�rde das so interpretieren, als dass der Linux-Kernel die

> (16)-Befehle nicht auf Verdacht nutzt, sondern dass irgendwelche

> Voraussetzungen (z.B. eine "all 1" R�ckmeldung auf den (10)-Befehl)
> vorliegen m�ssen.

Alte Ger�te haben READ_CAPACITY(16) nicht implementiert. Man w�rde sich
da also jedesmal eine Fehlermeldung einfangen. Das wollte man scheinbar
vermeiden.

Neue Ger�te m�ssen dagegen READ_CAPACITY(10) weiter unterst�tzen und
weil klar definiert ist, dass FFFFFFFFh gemeldet werden muss, wenn der
Wert nicht darstellbar ist, gibt es auch keine Zweifel wann genau man
danach zus�tzlich READ_CAPACITY(16) ausf�hren muss und wann nicht.


Micha

[Marc Haber]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>Marc Haber schrieb:
>> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:

>>>Wenn er nur Read Capacity (10) unterstützt, ist mit 2 TiB eben Ende.
>>>Jedenfalls bei 512-Byte-Sektoren. In früheren Versionen gab's übrigens noch
>>>keine Anforderung, 32 Einsen zu melden, wenn das Gerät die mögliche

>>>Kapazität überschreitet. Ist zwar eigentlich auch die logische Lösung, aber
>>>zumindest macht die Meldung einer zu kleinen Kapazität ja erstmal nichts

>>>kaputt.
>>
>> Kaputt macht es erst etwas, wenn der Host dann versucht, das zu klein
>> gemeldete Medium zu benutzen. Es gibt durchaus
>> Verwaltungsinformationen, die an das Ende des Devices geschrieben
>> werden, und das landet dann halt mitten in den Daten.
>

>Einfach so unabhängig davon, ob eventuell eine Partition eingerichtet ist,
>die bis dahin geht? Fände ich hochgradig grenzwertig. Und spätestens mit
>der Auswertung der Partitionstabellen muß man dann ohnehin die Pfoten von
>dem Medium lassen.

Ja, ok, geschenkt. Also geht spätestens dann was kaputt, wenn man
versucht, die scheinbar leere Platte zu partitionieren.

>>>> Aber Windows hat die korrekte Groesse erkannt, wenn ich mich nicht
>>>> verlesen habe. Weshalb es Marc ja unter Windows probiert hat,
>>>> was prompt schiefgegangen ist. Eben z.B. weil die Bridge
>>>> die 64-Bit-Befehle zwar akzeptiert, aber nicht korrekt weitergeleitet
>>>> hat.
>>>

>>>Ich tippe eher, daß Marc die Platte irgendwo per SATA mit Partitionen
>>>versehen hat und Windows gesehen hat, daß diese 3 TB umfassen. Und sich gar

>>>nicht um irgendwelche anderen Angaben geschert hat.
>>

>> Ich halte Deine Diagnose für korrekt.

>
>Das war ja eher ein sogenannter "educated guess". Da hat man bei Microsoft

>ja oft gute Karten, wenn man eine möglichst bescheuerte Implementation
>annimmt.

Deswegen war ich ja so neugierig und hab's ausprobiert. Man ist ja
nicht jeden Tag in der glücklichen Lage, eine 3-TB-Platte zum Spielen
zu haben. Inzwischen sind da wieder Livedaten drauf, es hat sich also
ausgespielt.

[Joseph Terner]

On Fri, 12 Apr 2013 11:34:44 +0200, Marc Haber wrote:

> Interessant finde ich, dass lsusb das Icy Box Gehäuse als Transcend
> StoreJet identifiziert. Ob da absichtlich eine Produktbezeichnung, die
> über den Chipsatz hinausgeht, in die usb.ids hinengerutscht ist? Die
> usb.ids kennt für Vendor 174c (ASMedia) überhaupt nur eine Product ID,
> und das ist die hier beobachtete 5106.

Ja, da hat jemand Unsinn eingetragen. Beim StoreJet 25M3 handelt es sich
um eine externe 2,5"-Festplatte:

<http://www.transcend-info.com/products/ModDetail.asp?ModNo=284>

Und da werden sicher auch noch andere Brückenchips zum Einsatz kommen.

Joseph