Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #243584 > unrolled thread

SSD von SanDisk brauchbar

Back to article view | Back to ger.ct

Contents

  SSD von SanDisk brauchbar Juergen <schreibsklave@web.de> - 2016-02-16 12:25 +0100
    Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-16 16:03 +0100
      Re: SSD von SanDisk brauchbar Peter Matthias <PeterMatthias@web.de> - 2016-02-16 22:03 +0100
        Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-16 22:14 +0100
          Re: SSD von SanDisk brauchbar Peter Matthias <PeterMatthias@web.de> - 2016-02-16 23:59 +0100
            Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-17 01:07 +0100
              Re: SSD von SanDisk brauchbar Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-02-19 14:42 +0100
                Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-20 11:26 +0100
                  Re: SSD von SanDisk brauchbar Michael Bode <m.g.bode@web.de> - 2016-02-20 12:44 +0100
                    Re: SSD von SanDisk brauchbar Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-02-20 12:54 +0100
                    Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-20 13:37 +0100
                      Re: SSD von SanDisk brauchbar Michael Bode <m.g.bode@web.de> - 2016-02-20 14:00 +0100
                        Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-22 13:39 +0100
                          Re: SSD von SanDisk brauchbar Michael Bode <m.g.bode@web.de> - 2016-02-22 20:09 +0100
                            Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-26 19:56 +0100
                              Re: SSD von SanDisk brauchbar Michael Bode <m.g.bode@web.de> - 2016-02-26 20:21 +0100
                                Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-27 12:03 +0100
                  Re: SSD von SanDisk brauchbar Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-02-20 12:49 +0100
                    Re: SSD von SanDisk brauchbar Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-02-20 12:57 +0100
                    Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-20 13:41 +0100
                      Re: SSD von SanDisk brauchbar Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-02-20 14:43 +0100
      Re: SSD von SanDisk brauchbar Bernd Lauert <m8r-9vv4fj@mailinator.com> - 2016-02-16 22:48 +0000
        Re: SSD von SanDisk brauchbar Frank Möller <butterspiegeleiauftoast84@net-24.at> - 2016-02-17 00:10 +0100
    Re: SSD von SanDisk brauchbar Shinji Ikari <shinji@gmx.net> - 2016-02-16 16:23 +0100
    Re: SSD von SanDisk brauchbar Thomas Niering <thomas.niering@arcor.de> - 2016-02-17 06:36 +0200

Page 1 of 2  [1] 2  Next page →

#243584 — SSD von SanDisk brauchbar

Servus.

Gibt es hier jemanden, der mit einer SSD von SanDisk,
insbesondere Modell Plus 480 GB (G25) schlechte Erfahrungen gemacht hat?

Ist mit 120 Euro gerade recht günstig zu haben.

Bewertungen bei Amazon reichen von "super" bis zu "totalausfall",
gemischt mit Installationsproblemen, Kritik das Laufwerk sei kaum
schneller als eine Festplatte oder gebe fiebende Pfeiftöne von sich.

Wie ich weiß, gibt es von SanDisk eine Software, die die SSD über
Windows mehr oder weniger ständig überwacht und Alarm schlagen soll,
wenn die "Reservesektoren" zur Neige gehen. Hatte nämlich im November
die kleinere Schwester dieser SSD für meinen neuen PC gekauft, würde die
jetzt aber lieber in ein Notebook einbauen.

Ich kenn SanDisk nur von CF-Karten, die halte ich für gut.
cu.
     Juergen

-- 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
 \   Freie Bits für frei Buerger     \
  \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[toc] | [next] | [standalone]

#243622

Juergen schrieb am Tue, 16 Feb 2016 12:25:52 +0100:

> Gibt es hier jemanden, der mit einer SSD von SanDisk,
> insbesondere Modell Plus 480 GB (G25) schlechte Erfahrungen gemacht hat?

> Ist mit 120 Euro gerade recht günstig zu haben.

Nun ja, z. B. eine Samsung 850 Evo mit 500 GB ist beim Preis pro GB nicht
viel teurer.

Ich kann von den Sandisks persönlich nix schlechtes sagen, ich hab nämlich
keine. Da ich aber seit einigen Jahren diverse Samsung 840 Pro und 850 Evo
im Einsatz habe, die ausgesprochen performant sind und bislang kein
einziges Problem zeigten, würde ich halt wieder die nehmen.

IMO ist bei Consumer-SSDs Samsung derzeit das Maß der Dinge.

> Bewertungen bei Amazon reichen von "super" bis zu "totalausfall",
> gemischt mit Installationsproblemen, Kritik das Laufwerk sei kaum
> schneller als eine Festplatte oder gebe fiebende Pfeiftöne von sich.

> Wie ich weiß, gibt es von SanDisk eine Software, die die SSD über
> Windows mehr oder weniger ständig überwacht und Alarm schlagen soll,
> wenn die "Reservesektoren" zur Neige gehen. Hatte nämlich im November
> die kleinere Schwester dieser SSD für meinen neuen PC gekauft, würde die
> jetzt aber lieber in ein Notebook einbauen.

> Ich kenn SanDisk nur von CF-Karten, die halte ich für gut.

Bei CF-Karten nutze ich auch Sandisks. Allerdings haben die mit SSDs 
- insbesondere bei der Controller-Technologie - herzlich wenig zu tun.

-- 

[toc] | [prev] | [next] | [standalone]

#243686

Am 16.02.2016 um 16:03 schrieb Frank Möller:
> Da ich aber seit einigen Jahren diverse Samsung 840 Pro und 850 Evo
> im Einsatz habe, die ausgesprochen performant sind und bislang kein
> einziges Problem zeigten, würde ich halt wieder die nehmen.
>
> IMO ist bei Consumer-SSDs Samsung derzeit das Maß der Dinge.

Also meine Samsung SSD 840 EVO 120GB wurde mit der Zeit unglaublich 
lahm. Samsung konnte den Fehler erst im 2. Anlauf fixen. Und ich bin mir 
nicht wirklich sicher, ob die Datenpartition nicht auch Datenverlust 
hat. Samsung? Nein Danke.

Peter

[toc] | [prev] | [next] | [standalone]

#243689

Peter Matthias schrieb am Tue, 16 Feb 2016 22:03:49 +0100:
> Am 16.02.2016 um 16:03 schrieb Frank Möller:

>> Da ich aber seit einigen Jahren diverse Samsung 840 Pro und 850 Evo
>> im Einsatz habe, die ausgesprochen performant sind und bislang kein
>> einziges Problem zeigten, würde ich halt wieder die nehmen.

>> IMO ist bei Consumer-SSDs Samsung derzeit das Maß der Dinge.

> Also meine Samsung SSD 840 EVO 120GB wurde mit der Zeit unglaublich
> lahm. Samsung konnte den Fehler erst im 2. Anlauf fixen. Und ich bin mir
> nicht wirklich sicher, ob die Datenpartition nicht auch Datenverlust
> hat.

Tja, das könnte unter Linux aber möglicherweise auch ganz schlicht an einem
Bug im Linux Kernel gelegen haben und betraf bei weitem nicht nur Samsung
SSDs, sondern alle SSDs, siehe z. B.:
<https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

Übrigens war es Samsung, die dafür einen Kernelpatch zur Verfügung gestellt
haben, der in der Folge in die Distris eingepflegt wurde. Witzig, oder?

> Samsung? Nein Danke.

Tja, mußt Du wissen. Ich denke eher, Du urteilst vorschnell.

-- 

[toc] | [prev] | [next] | [standalone]

#243704

Am 16.02.2016 um 22:14 schrieb Frank Möller:
>> Also meine Samsung SSD 840 EVO 120GB wurde mit der Zeit unglaublich
>> >lahm. Samsung konnte den Fehler erst im 2. Anlauf fixen. Und ich bin mir
>> >nicht wirklich sicher, ob die Datenpartition nicht auch Datenverlust
>> >hat.
> Tja, das könnte unter Linux aber möglicherweise auch ganz schlicht an einem
> Bug im Linux Kernel gelegen haben und betraf bei weitem nicht nur Samsung
> SSDs, sondern alle SSDs, siehe z. B.:
> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

Wenn ich die Seite richtig gelesen habe, hat die Firmware der SSD das 
TRIM Kommando falsch interpretiert. Sieht doch sehr nach Firmwarefehler aus.

> Übrigens war es Samsung, die dafür einen Kernelpatch zur Verfügung gestellt
> haben, der in der Folge in die Distris eingepflegt wurde. Witzig, oder?

Ein Blacklist für TRIM?

>> >Samsung? Nein Danke.
> Tja, mußt Du wissen. Ich denke eher, Du urteilst vorschnell.

Bei meiner SSD ist es ziemlich sicher (auch) etwas anderes. Ich halte 
mich bei so etwas für ziemlich konsequent.

Peter

[toc] | [prev] | [next] | [standalone]

#243710

Peter Matthias schrieb am Tue, 16 Feb 2016 23:59:31 +0100:
> Am 16.02.2016 um 22:14 schrieb Frank Möller:

>>> Also meine Samsung SSD 840 EVO 120GB wurde mit der Zeit unglaublich
>>> lahm. Samsung konnte den Fehler erst im 2. Anlauf fixen. Und ich bin mir
>>> nicht wirklich sicher, ob die Datenpartition nicht auch Datenverlust
>>> hat.

>> Tja, das könnte unter Linux aber möglicherweise auch ganz schlicht an einem
>> Bug im Linux Kernel gelegen haben und betraf bei weitem nicht nur Samsung
>> SSDs, sondern alle SSDs, siehe z. B.:
>> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

> Wenn ich die Seite richtig gelesen habe, hat die Firmware der SSD das
> TRIM Kommando falsch interpretiert. Sieht doch sehr nach Firmwarefehler aus.

Nein, AFAIR wurde das Problem zwar bei Samsung SSDs bemerkt, hat sich
letztlich aber als Bug im Kernel herausgestellt und betraf alle. Wurde IIRC
auch in de.comp.hardware.laufwerke.festplatten z. B. von Jürgen P. Meier
bestätigt.

>> Übrigens war es Samsung, die dafür einen Kernelpatch zur Verfügung gestellt
>> haben, der in der Folge in die Distris eingepflegt wurde. Witzig, oder?

> Ein Blacklist für TRIM?

Äh, wie meinen?

>>>> Samsung? Nein Danke.
>> Tja, mußt Du wissen. Ich denke eher, Du urteilst vorschnell.

> Bei meiner SSD ist es ziemlich sicher (auch) etwas anderes. Ich halte
> mich bei so etwas für ziemlich konsequent.

Ist ja Ok, ich hab auch Sachen, die ich "einfach nicht mag". Kann
vorkommen.

-- 

[toc] | [prev] | [next] | [standalone]

#244125

Am 17.02.2016 um 01:07 schrieb Frank Möller:
> ...
>
> Nein, AFAIR wurde das Problem zwar bei Samsung SSDs bemerkt, hat sich
> letztlich aber als Bug im Kernel herausgestellt und betraf alle. Wurde IIRC
> auch in de.comp.hardware.laufwerke.festplatten z. B. von Jürgen P. Meier
> bestätigt.

Da gab es heiße Wortwechsel.
Ich entnahm den Äußerungen, dass Samsung in seiner Firmware etwas 
zusicherte, nicht einhielt und daraufhin blacklistet wurde.

z.B. findest man im meinem Rechner den folgenden Vermerk unter:
/usr/src/linux-3.16.7-32/drivers/ata/libata-core.c


/* devices that don't properly handle queued TRIM commands */
	{ "Micron_M500*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM, },
	{ "Crucial_CT???M500SSD*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM, },
	{ "Micron_M550*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM, },
	{ "Crucial_CT*M550SSD*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM, },
	{ "Samsung SSD 8*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM, },


Gruß
Peter

[toc] | [prev] | [next] | [standalone]

#244238

Peter Mc Donough schrieb am Fri, 19 Feb 2016 14:42:34 +0100:
> Am 17.02.2016 um 01:07 schrieb Frank Möller:

>> Nein, AFAIR wurde das Problem zwar bei Samsung SSDs bemerkt, hat sich
>> letztlich aber als Bug im Kernel herausgestellt und betraf alle. Wurde IIRC
>> auch in de.comp.hardware.laufwerke.festplatten z. B. von Jürgen P. Meier
>> bestätigt.

> Da gab es heiße Wortwechsel.
> Ich entnahm den Äußerungen, dass Samsung in seiner Firmware etwas
> zusicherte, nicht einhielt und daraufhin blacklistet wurde.

> z.B. findest man im meinem Rechner den folgenden Vermerk unter:
> /usr/src/linux-3.16.7-32/drivers/ata/libata-core.c
           ^^^^^^^^^^

Was hat 3.16 damit zu tun? Bereits im Dez. 2014 erschien 3.18. Aber auch
das hat noch herzlich wenig mit dem zu tun, was erst in der Folge geschah.

Juni 2105:

<https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

| UPDATE July 17:
| We have just finished a conference call with Samsung considering the
| failure analysis of this issue. Samsung engineering team has been able
| to successfully reproduce the issue with our latest provided binary.
|
| Samsung had a concrete conclusion that the issue is not related to
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Samsung SSD or Algolia software but is related to the Linux kernel.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| Samsung has developed a kernel patch to resolve this issue and the^
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| official statement with details will be released tomorrow, July 18 on
| Linux community with the Linux patch guide. Our testing code is
| available on GitHub.
|
| This has been an amazing ride, thank you everyone for joining, we have
| arrived at the destination.
|
| For all followers of this blogpost and all the new readers:
|
| The discovered issue has much bigger impact than we originally expected
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| and is not caused by Samsung SSDs, as we originally assumed.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| My personal apologies to Samsung!


Und am 21. Juni 2015 erschien als Folge Kernel 4.1.

Wer immer noch meint, Samsung "sei schuld", hat da also ganz offensichtlich
längere Zeit verschiedenes nicht mitgekriegt oder nicht mitkriegen wollen,
denn tatsächlich hat Samsung das Linux-Problem _gelöst_.

-- 

[toc] | [prev] | [next] | [standalone]

#244261

Am 20.02.2016 um 11:26 schrieb Frank Möller:

>> z.B. findest man im meinem Rechner den folgenden Vermerk unter:
>> /usr/src/linux-3.16.7-32/drivers/ata/libata-core.c
>            ^^^^^^^^^^
> 
> Was hat 3.16 damit zu tun? Bereits im Dez. 2014 erschien 3.18. Aber auch
> das hat noch herzlich wenig mit dem zu tun, was erst in der Folge geschah.
> 
> Juni 2105
> 
> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

Und in 4.2 steht das immer noch drin. Es sind übrigens eine ganze Menge
Devices wegen aller mögliche Gründe geblacklistet.

Soweit ich das verstanden habe, sind das 2 verschiedene Fehler. In
(u.a.) der Samsung Firmware funktioniert *queued* TRIM nicht richtig.
Und im Kernel war ein Bug im Code für RAID0/10 der mit *non-queued* TRIM
zusammenhängt. Der Kernel Bug wurde von Samsung gefunden und gefixed,
der Firmware Bug nicht.

[toc] | [prev] | [next] | [standalone]

#244264

Am 20.02.2016 um 12:44 schrieb Michael Bode:

> ...
>
> Soweit ich das verstanden habe, sind das 2 verschiedene Fehler. In
> (u.a.) der Samsung Firmware funktioniert *queued* TRIM nicht richtig.
> Und im Kernel war ein Bug im Code für RAID0/10 der mit *non-queued* TRIM
> zusammenhängt. Der Kernel Bug wurde von Samsung gefunden und gefixed,
> der Firmware Bug nicht.

Jeder was er kann: Die Linux-Leute können Bugs fixen.

Gruß
Peter

[toc] | [prev] | [next] | [standalone]

#244270

Michael Bode schrieb am Sat, 20 Feb 2016 12:44:49 +0100:
> Am 20.02.2016 um 11:26 schrieb Frank Möller:

>> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>

> Und in 4.2 steht das immer noch drin. Es sind übrigens eine ganze Menge
> Devices wegen aller mögliche Gründe geblacklistet.

> Soweit ich das verstanden habe, sind das 2 verschiedene Fehler. In
> (u.a.) der Samsung Firmware funktioniert *queued* TRIM nicht richtig.
> Und im Kernel war ein Bug im Code für RAID0/10 der mit *non-queued* TRIM
> zusammenhängt. Der Kernel Bug wurde von Samsung gefunden und gefixed,
> der Firmware Bug nicht.

Für die 840 Evo gab es im Okt. 2014 ein Firmware-Update. Wenn es darüber
hinaus noch einen Firmware Bug gegeben hätte, würde der unter anderen
Systemen auch zuschlagen. Bei der Vielzahl an Windows-Systemen mit SSDs
wäre das zwangsläufig aufgefallen.

Da das aber nicht so ist, sieht mir das eher so aus, daß es den behaupteten
Firmware Bug gar nicht gab/gibt, sondern daß das halt eine Linux-Sache
war/ist. Und wenn dazu dann von Seiten der Linux-Macher gesagt wird, das
ist behoben, und zwar dank der Hilfe von Samsung selber, dann ist mir nicht
klar, wieso das geleugnet wird.

-- 

[toc] | [prev] | [next] | [standalone]

#244278

Am 20.02.2016 um 13:37 schrieb Frank Möller:
> Michael Bode schrieb am Sat, 20 Feb 2016 12:44:49 +0100:
>> Am 20.02.2016 um 11:26 schrieb Frank Möller:
> 
>>> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>
> 
>> Und in 4.2 steht das immer noch drin. Es sind übrigens eine ganze Menge
>> Devices wegen aller mögliche Gründe geblacklistet.
> 
>> Soweit ich das verstanden habe, sind das 2 verschiedene Fehler. In
>> (u.a.) der Samsung Firmware funktioniert *queued* TRIM nicht richtig.
>> Und im Kernel war ein Bug im Code für RAID0/10 der mit *non-queued* TRIM
>> zusammenhängt. Der Kernel Bug wurde von Samsung gefunden und gefixed,
>> der Firmware Bug nicht.
> 
> Für die 840 Evo gab es im Okt. 2014 ein Firmware-Update. Wenn es darüber
> hinaus noch einen Firmware Bug gegeben hätte, würde der unter anderen
> Systemen auch zuschlagen. Bei der Vielzahl an Windows-Systemen mit SSDs
> wäre das zwangsläufig aufgefallen.

Hast du mal das Changelog für das Firmwareupdate von Okt. 2014?
Zu anderen Systemen hab ich bisher nur gefunden, dass die kein qeued
TRIM verwenden. Also tritt der Bug da auch nicht auf. Wenn jemand andere
Informationen hat, immer her damit.

> Da das aber nicht so ist, sieht mir das eher so aus, daß es den behaupteten
> Firmware Bug gar nicht gab/gibt, sondern daß das halt eine Linux-Sache
> war/ist. Und wenn dazu dann von Seiten der Linux-Macher gesagt wird, das
> ist behoben, und zwar dank der Hilfe von Samsung selber, dann ist mir nicht
> klar, wieso das geleugnet wird.

Wer leugnet denn, dass Samsung einen Bug im Linux RAID Code gefixed hat?

[toc] | [prev] | [next] | [standalone]

#244625

Michael Bode schrieb am Sat, 20 Feb 2016 14:00:40 +0100:
> Am 20.02.2016 um 13:37 schrieb Frank Möller:
>> Michael Bode schrieb am Sat, 20 Feb 2016 12:44:49 +0100:

>>> Soweit ich das verstanden habe, sind das 2 verschiedene Fehler. In
>>> (u.a.) der Samsung Firmware funktioniert *queued* TRIM nicht richtig.
>>> Und im Kernel war ein Bug im Code für RAID0/10 der mit *non-queued* TRIM
>>> zusammenhängt. Der Kernel Bug wurde von Samsung gefunden und gefixed,
>>> der Firmware Bug nicht.

>> Für die 840 Evo gab es im Okt. 2014 ein Firmware-Update. Wenn es darüber
>> hinaus noch einen Firmware Bug gegeben hätte, würde der unter anderen
>> Systemen auch zuschlagen. Bei der Vielzahl an Windows-Systemen mit SSDs
>> wäre das zwangsläufig aufgefallen.

> Hast du mal das Changelog für das Firmwareupdate von Okt. 2014?

Ich hatte
<http://www.tomshardware.de/samsung-ssd-840-evo-firmware-update,news-251512.html>
gelesen, aber kein Changelog gesucht.

> Zu anderen Systemen hab ich bisher nur gefunden, dass die kein qeued
> TRIM verwenden. Also tritt der Bug da auch nicht auf. Wenn jemand andere
> Informationen hat, immer her damit.

Nun ja, Queued Trim ist ein Feature, welches mit SATA 3.1 eingeführt wurde.
Die fraglichen SSDs sind AFAIK jedoch für SATA 3.0 (oder kleiner)
spezifiziert. Wer nun erwartet, daß solche neuen Features von SATA 3.1 mit
Geräten mit SATA 3.0 (oder früher) funktionieren, obwohl diese Geräte oder
die Ports dafür noch nicht spezifiziert sind, muß sich dann wohl fragen
lassen, was das soll.

Es ist IMO ganz normal, daß das nicht funktioniert, wenn
- der Port nicht SATA 3.1 vollumfänglich unterstützt und 
- das Gerät nicht ebenfalls SATA 3.1 vollumfänglich unterstützt und
- ein beteiligtes Software-Modul (Treiber) nicht ebenfalls SATA 3.1 
  vollumfänglich unterstützt.

Wollte man ein Gerät für USB 2.0 mit USB 3.0 ansprechen, würde sich niemand
wundern, wenn das nicht entsprechend funktioniert. Aber bei SATA erwartet
man das? Wieso denn? Offenbar sind hier wohl ein paar Geeks ihrer Zeit zu
sehr voraus.

-- 

[toc] | [prev] | [next] | [standalone]

#244703

Am 22.02.2016 um 13:39 schrieb Frank Möller:

> Nun ja, Queued Trim ist ein Feature, welches mit SATA 3.1 eingeführt wurde.
> Die fraglichen SSDs sind AFAIK jedoch für SATA 3.0 (oder kleiner)
> spezifiziert. Wer nun erwartet, daß solche neuen Features von SATA 3.1 mit
> Geräten mit SATA 3.0 (oder früher) funktionieren, obwohl diese Geräte oder
> die Ports dafür noch nicht spezifiziert sind, muß sich dann wohl fragen
> lassen, was das soll.

Dann würde es ja wohl Sinn machen, queued TRIM für diese SSDs nicht zu
verwenden. Daher das Blacklisting.

Nebenbei, scheint Samsung hier nicht mitzulesen und ist wohl anderer
Meinung, was den queued TRIM Support in SATA 3.0 angeht:

http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02_Understanding_SSD_System_Requirements.pdf

[toc] | [prev] | [next] | [standalone]

#245233

Michael Bode schrieb am Mon, 22 Feb 2016 20:09:32 +0100:
> Am 22.02.2016 um 13:39 schrieb Frank Möller:

>> Nun ja, Queued Trim ist ein Feature, welches mit SATA 3.1 eingeführt wurde.
>> Die fraglichen SSDs sind AFAIK jedoch für SATA 3.0 (oder kleiner)
>> spezifiziert. Wer nun erwartet, daß solche neuen Features von SATA 3.1 mit
>> Geräten mit SATA 3.0 (oder früher) funktionieren, obwohl diese Geräte oder
>> die Ports dafür noch nicht spezifiziert sind, muß sich dann wohl fragen
>> lassen, was das soll.

> Dann würde es ja wohl Sinn machen, queued TRIM für diese SSDs nicht zu
> verwenden. Daher das Blacklisting.

AFAIS wäre es dann halt sinnvoll, Queued TRIM einfach nicht zu verwenden,
solange man nicht sicher sein kann, daß alle beteiligten Komponenten es
voll beherrschen.

> Nebenbei, scheint Samsung hier nicht mitzulesen und ist wohl anderer
> Meinung, was den queued TRIM Support in SATA 3.0 angeht:

> http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02_Understanding_SSD_System_Requirements.pdf

Nun, dann haben sie es offenbar auch in Geräte mit SATA 3.0 bereits
implementiert. Ist dann nicht alles bestens?

AFAIS müßte Man lediglich noch prüfen, ob die Ports, an denen diese SSDs
angeschlossen werden, die Befehle für Queued TRIM auch korrekt übermitteln.

Na ja, mir persönlich kann's ja egal sein. Ich verwende Windows 7 und meine
sämtlichen Samsung SSDs funktionieren in genau einer Weise: bestens.

-- 

[toc] | [prev] | [next] | [standalone]

#245242

Am 26.02.2016 um 19:56 schrieb Frank Möller:

>> Dann würde es ja wohl Sinn machen, queued TRIM für diese SSDs nicht zu
>> verwenden. Daher das Blacklisting.
> 
> AFAIS wäre es dann halt sinnvoll, Queued TRIM einfach nicht zu verwenden,
> solange man nicht sicher sein kann, daß alle beteiligten Komponenten es
> voll beherrschen.

Genau das ist ja der Sinn des Blacklistings, wie ich schon schrieb.

>> Nebenbei, scheint Samsung hier nicht mitzulesen und ist wohl anderer
>> Meinung, was den queued TRIM Support in SATA 3.0 angeht:
> 
>> http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02_Understanding_SSD_System_Requirements.pdf
> 
> Nun, dann haben sie es offenbar auch in Geräte mit SATA 3.0 bereits
> implementiert. Ist dann nicht alles bestens?

Bestens wäre es, wenn sie es richtig implementiert hätten.

> Na ja, mir persönlich kann's ja egal sein. Ich verwende Windows 7 und meine
> sämtlichen Samsung SSDs funktionieren in genau einer Weise: bestens.

Unter Linux funktionieren die genauso gut, seit sie halt nicht mit
Funktionen betrieben werden, die sie nicht richtig können. Und seit
Samsung den anderen Bug gefunden hat.

[toc] | [prev] | [next] | [standalone]

#245271

Michael Bode schrieb am Fri, 26 Feb 2016 20:21:10 +0100:
> Am 26.02.2016 um 19:56 schrieb Frank Möller:

>>> http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02_Understanding_SSD_System_Requirements.pdf

>> Nun, dann haben sie es offenbar auch in Geräte mit SATA 3.0 bereits
>> implementiert. Ist dann nicht alles bestens?

> Bestens wäre es, wenn sie es richtig implementiert hätten.

Es bleibt halt die Frage, ob es wirklich an ihnen liegt. Womöglich ist auch
das eine Kernel-Geschichte oder das Zusammenspiel mit Controllern mit SATA
3.0 oder kleiner funktioniert nicht entsprechend. Jedenfalls wäre ich mit
Schuldzuweisungen vorsichtig, solange nicht wirklich klar ist, was da
klemmt. Bei dem anderen Bug, den man Samsung angelastet hat, lag es auch
nicht an ihnen, sondern an Linux, und Samsung hat ihn vielmehr gelöst.

-- 

[toc] | [prev] | [next] | [standalone]

#244262

Am 20.02.2016 um 11:26 schrieb Frank Möller:
> Peter Mc Donough schrieb am Fri, 19 Feb 2016 14:42:34 +0100:
>> Am 17.02.2016 um 01:07 schrieb Frank Möller:
> ...
>> Da gab es heiße Wortwechsel.
>> Ich entnahm den Äußerungen, dass Samsung in seiner Firmware etwas
>> zusicherte, nicht einhielt und daraufhin blacklistet wurde.
>
>> z.B. findest man im meinem Rechner den folgenden Vermerk unter:
>> /usr/src/linux-3.16.7-32/drivers/ata/libata-core.c
>             ^^^^^^^^^^
>
> Was hat 3.16 damit zu tun? Bereits im Dez. 2014 erschien 3.18. Aber auch
> das hat noch herzlich wenig mit dem zu tun, was erst in der Folge geschah.

Das ist das, was auf meinem Rechner ist.
Was bei anderen /usr/src/linux_.../drivers/ata/libata-core.c blacklistet 
ist, kann ich nicht nachsehen.

>
> Juni 2105:
> <https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>
> | UPDATE July 17:
> | We have just finished a conference call with Samsung considering the
> | failure analysis of this issue. Samsung engineering team has been able
> | to successfully reproduce the issue with our latest provided binary.
...

Ich folge damals dem Schriftwechsel und Kommentare dazu
(im August 2015 (!)
Die Essenz für mich wie angegeben: Die Samsung-Firmware hielt nicht, was 
Samsung behauptete.
...

> Und am 21. Juni 2015 erschien als Folge Kernel 4.1.
Ja, und das nützt dir genau wieviel, wenn du den Kernel 3.16 verwendest.

> Wer immer noch meint, Samsung "sei schuld", hat da also ganz offensichtlich
> längere Zeit verschiedenes nicht mitgekriegt oder nicht mitkriegen wollen,
> denn tatsächlich hat Samsung das Linux-Problem _gelöst_.
>

Ich bin in der Lage, das zu beurteilen.
Wesentlich ist, wenn ich Hardware kaufe, sehe ich vorher nach, ob sie 
Probleme verursachen könnte.

In dem Fall hatte die Samsung SSD Probleme, die ander SSDs nicht hatten 
und ich vermute nicht, dass andere Hersteller ihre Firmware an Linux 
anpassen.

Gruß
Peter

[toc] | [prev] | [next] | [standalone]

#244265

Am 20.02.2016 um 12:49 schrieb Peter Mc Donough:

> ...
Sorry, sollte heißen:
> Ich bin in der Lage, das zu beurteilen.
Ich bin nicht in der Lage, das zu beurteilen.....

Gruß
Peter

[toc] | [prev] | [next] | [standalone]

#244271

Peter Mc Donough schrieb am Sat, 20 Feb 2016 12:49:09 +0100:
> Am 20.02.2016 um 11:26 schrieb Frank Möller:

> Ich folge damals dem Schriftwechsel und Kommentare dazu
> (im August 2015 (!)
> Die Essenz für mich wie angegeben: Die Samsung-Firmware hielt nicht, was
> Samsung behauptete.

Dummerweise steht das unter
<https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/>
jedoch anders.

>> Und am 21. Juni 2015 erschien als Folge Kernel 4.1.
> Ja, und das nützt dir genau wieviel, wenn du den Kernel 3.16 verwendest.

Wenn man derartig wichtige Updates verweigert, dann ist das genau dasselbe
wie bei Windows: Typischer Fall von SZ = Selbert Zschuld.

-- 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | ger.ct

csiph-web