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

[Helmut Hullen]

Hallo, Marc,

Post by Marc Haber
|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

[...]

Post by Marc Haber
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]

Post by Helmut Hullen

Post by Marc Haber
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?

Post by Helmut Hullen
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?

Grüße
Marc

[Helmut Hullen]

Hallo, Marc,

Post by Marc Haber

Post by Helmut Hullen

Post by Marc Haber
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


Viele Gruesse
Helmut

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

[Henning Paul]

Post by Helmut Hullen

Post by Marc Haber

Post by Helmut Hullen

Post by Marc Haber
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]

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

Und wie soll die funktionieren?

Post by Helmut Hullen
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?

Post by Helmut Hullen
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.

Post by Helmut Hullen
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.

Grüße
Marc

[Helmut Hullen]

Hallo, Marc,

Post by Marc Haber

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

Und wie soll die funktionieren?

Post by Helmut Hullen
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.

Post by Marc Haber

Post by Helmut Hullen
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.

Post by Marc Haber
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.

Viele Gruesse
Helmut

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

[Marc Haber]

Post by Helmut Hullen

Post by Marc Haber
Was ist eine normale und was ist eine unnormale SATA-Platte?

"normal": Blockgrösse 512 Byte.

Das liegt hier ausweislich des Syslogs zweifelsfrei vor.

Grüße
Marc

[Marc Haber]

Post by Marc Haber
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.

Grüße
Marc

[Henning Paul]

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

Alles andere hätte mich auch gewundert.

Post by Marc Haber
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]

Post by Marc Haber
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]

Post by Dirk Thierbach
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.

Post by Dirk Thierbach
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 :-(

Grüße
Marc

[Martin Schoenbeck]

Hallo Dirk,

Post by Dirk Thierbach
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

[Marc Haber]

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Grüße
Marc

[Martin Schoenbeck]

Hallo Marc,

Post by Marc Haber

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Gruß Martin

[Dirk Thierbach]

Post by Martin Schoenbeck
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,

Post by Dirk Thierbach

Post by Martin Schoenbeck
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?

Post by Dirk Thierbach
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.

Gruß Martin

[Dirk Thierbach]

Post by Martin Schoenbeck
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).

Post by Martin Schoenbeck
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

[Martin Schoenbeck]

Hallo Dirk,

Post by Dirk Thierbach

Post by Martin Schoenbeck
Liest Du eigentlich, worauf Du antwortest?

: 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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach
(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.

Post by Dirk Thierbach
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?

Post by Dirk Thierbach
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.

Post by Dirk Thierbach
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.

Gruß Martin

[Dirk Thierbach]

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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.

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

Huh? Wie stellst Du Dir das konkret vor?

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
Bei mir gab es keinerlei Unklarheiten.

Siehe oben.

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
obwohl es gar nicht um Linux ging.

Entschuldige bitte.

- Dirk

[Martin Schoenbeck]

Hallo Dirk,

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Post by Martin Schoenbeck
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.

Gruß Martin

[Marc Haber]

Post by Martin Schoenbeck
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.

Grüße
Marc

[Dirk Thierbach]

Post by Martin Schoenbeck

Post by Dirk Thierbach

Post by Martin Schoenbeck
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?

Post by Martin Schoenbeck

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck
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

[Martin Schoenbeck]

Hallo Dirk,

Post by Dirk Thierbach

Post by Martin Schoenbeck

Post by Dirk Thierbach

Post by Martin Schoenbeck
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?

Post by Martin Schoenbeck

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach
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.

Post by Dirk Thierbach
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ß.

Post by Dirk Thierbach
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Gruß Martin

[Marc Haber]

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Post by Dirk Thierbach
Die Bedingungen dazu sind etwas komplex, die
habe ich mir nicht genau angeschaut.

Ist es das was Du meinst?

Grüße
Marc

[Michael Baeuerle]

Post by Marc Haber
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]

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Grüße
Marc

[Martin Schoenbeck]

Hallo Marc,

Post by Marc Haber

Post by Martin Schoenbeck
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.

Post by Marc Haber

Post by Martin Schoenbeck

Post by Dirk Thierbach
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

Post by Marc Haber

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Gruß Martin

[Marc Haber]

Post by Martin Schoenbeck

Post by Marc Haber

Post by Martin Schoenbeck
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.

Post by Martin Schoenbeck

Post by Marc Haber

Post by Martin Schoenbeck

Post by Dirk Thierbach
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.

Grüße
Marc

[Helmut Hullen]

Hallo, Martin,

Du meintest am 09.04.13:

[...]

Post by Martin Schoenbeck

Post by Dirk Thierbach
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).

Viele Gruesse
Helmut

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

[Marc Haber]

Post by Helmut Hullen
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.

Grüße
Marc

[Dirk Thierbach]

Post by Dirk Thierbach
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

[Henning Paul]

Post by Dirk Thierbach

Post by Dirk Thierbach
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.

Post by Dirk Thierbach
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:

***@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
***@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:

***@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]

Post by Henning Paul
Bei der wie erwähnt ebenfalls fehlerhaft funktionierenden "152d:2338
JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed
Last logical block address=1565565871 (0x5d50a3af), Number of
blocks=1565565872
Logical block length=512 bytes
Device size: 801569726464 bytes, 764436.5 MiB, 801.57 GB
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.

Post by Henning Paul
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.

Grüße
Marc

[Marc Haber]

Post by Henning Paul
Eine "152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
READ CAPACITY (10) indicates device capacity too large
now trying 16 byte cdb variant
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
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.

Grüße
Marc

[Joseph Terner]

Post by Marc Haber
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

[Helmut Hullen]

Hallo, Dirk,

Post by Dirk Thierbach

Post by Martin Schoenbeck
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.

Viele Gruesse
Helmut

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

[Dirk Thierbach]

Post by Marc Haber
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

[Marc Haber]

Post by Dirk Thierbach

Post by Marc Haber
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?

Grüße
Marc

[Dirk Thierbach]

Post by Marc Haber

Post by Dirk Thierbach

Post by Marc Haber
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

[Marc Haber]

Post by Dirk Thierbach
Ich dachte, Du redest von Linux. Wie im Gruppennamen.

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

Grüße
Marc

[Heiko Schlenker]

Post by Marc Haber
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.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker

Post by Marc Haber
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?

Gruß Martin

[Heiko Schlenker]

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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?

Gruß Martin

[Heiko Schlenker]

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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?

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.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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?

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.

Gruß Martin

[Heiko Schlenker]

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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?

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?

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

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. Vermutlich bist Du im
Diskussionsstrang verrutscht. Mir geht es um Marcs Anforderung an ein
OS, welche nach meinem Dafürhalten schwierig zu erfüllen ist.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Martin Schoenbeck

Post by Heiko Schlenker

Post by Marc Haber
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?

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?

Offensichtlich. Henning Paul geht in Artikel
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.

Post by Heiko Schlenker
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.

Post by Heiko Schlenker
Vermutlich bist Du im
Diskussionsstrang verrutscht.

Definitiv nicht.

Post by Heiko Schlenker
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.

Gruß Martin

[Heiko Schlenker]

Post by Heiko Schlenker

Post by Marc Haber
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.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker

Post by Heiko Schlenker

Post by Marc Haber
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.

Gruß Martin

[Heiko Schlenker]

Post by Heiko Schlenker

Post by Heiko Schlenker

Post by Heiko Schlenker

Post by Marc Haber
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.

^^^^^^^^^^^^^^^^^^^^^

Post by Heiko Schlenker
Nö, es ist keine notwendige Bedingung formuliert worden, sondern eine
hinreichende.

Also wieder nur eine Banalität.

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.

Gruß, Heiko

[Martin Schoenbeck]

Hallo Heiko,

Post by Heiko Schlenker
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.

Gruß Martin

[Marc Haber]

Post by Dirk Thierbach
Mit anderen Worten, die bisherige Diagnose war wohl richtig

Genau.

Grüße
Marc

[Henning Paul]

Post by Marc Haber
Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB

Google sagt, damit bist Du nicht er einzige.

Post by Marc Haber
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)

[Marc Haber]

Post by Henning Paul

Post by Marc Haber
Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB

Google sagt, damit bist Du nicht er einzige.

Post by Marc Haber
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.

Grüße
Marc

[Joseph Terner]

Post by Marc Haber

Post by Henning Paul

Post by Marc Haber
Wenn ich dort eine 3-TB-Platte hineinstecke, wird sie nur mit 801 GB

Google sagt, damit bist Du nicht er einzige.

Post by Marc Haber
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.

Post by Marc Haber

Post by Henning Paul
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

[Hermann Riemann]

Post by Marc Haber
Wenn ich dort eine 3-TB-Platte hineinstecke,
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.