ssd TRIM (noch einmal) und Rescue-DVD/Stick
Mir ist noch etwas eingefallen. Für Backupzwecke nutze ich einen Rescue-Stick mit suse 13.1, obwohl auf meinem Rechner die 13.2 läuft. Hauptgrund: Die 13.2 Rescue-iso ist auf dem Stick aus was für Grunden auch immer Ar...langsam. Bisher keine Probleme. Jetzt die SSD. Mann könnte ja vermuten, dass die die Rescue-ISOs sehr konservativ zusammengestellt wurden und die TRIM-Problematik keine Rolle spielt. Mit Vermutungen bei Computern ist das so eine Sache. Ich hätte das gerne genauer gewusst. Nachgesehen auf dem Stick habe ich schon, vermutlich kann ich nicht finden, weil das in den Kernel compiliert sein dürfte. Weiß jemand mehr? Gruß Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Wed, 05 Aug 2015, Peter Mc Donough schrieb:
Mir ist noch etwas eingefallen. [..] Jetzt die SSD. Mann könnte ja vermuten, dass die die Rescue-ISOs sehr konservativ zusammengestellt wurden und die TRIM-Problematik keine Rolle spielt. Mit Vermutungen bei Computern ist das so eine Sache. Ich hätte das gerne genauer gewusst.
Nachgesehen auf dem Stick habe ich schon, vermutlich kann ich nicht finden, weil das in den Kernel compiliert sein dürfte.
Du könntest probieren: zcat /boot/vmlinuz-$VERSION | strings | grep 'Samsung SSD', das klappt aber nicht bei jedem Kernel. (wg.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9...) Wenn du auf Nummer sicher gehen willst, schalt NCQ komplett ab: libata.force=noncq als Kernelparameter. Ansonsten mount eben ohne das automatische trimmen und laß die Finger von 'fstrim' ;) HTH, -dnh -- "Ich habe überhaupt keine Hoffnung mehr in die Zukunft unseres Landes, wenn einmal unsere Jugend die Männer von morgen stellt. Unsere Jugend ist unerträglich,unverantwortlich und entsetzlich anzusehen" -- Aristoteles -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Thu, 6 Aug 2015 05:05:32 +0200 David Haller <dnh@opensuse.org> wrote:
Hallo,
Am Wed, 05 Aug 2015, Peter Mc Donough schrieb:
Mir ist noch etwas eingefallen. [..] Jetzt die SSD. Mann könnte ja vermuten, dass die die Rescue-ISOs sehr konservativ zusammengestellt wurden und die TRIM-Problematik keine Rolle spielt. Mit Vermutungen bei Computern ist das so eine Sache. Ich hätte das gerne genauer gewusst.
Nachgesehen auf dem Stick habe ich schon, vermutlich kann ich nicht finden, weil das in den Kernel compiliert sein dürfte.
Du könntest probieren:
zcat /boot/vmlinuz-$VERSION | strings | grep 'Samsung SSD', das klappt aber nicht bei jedem Kernel.
(wg.: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9...)
Wenn du auf Nummer sicher gehen willst, schalt NCQ komplett ab:
libata.force=noncq
als Kernelparameter. Ansonsten mount eben ohne das automatische trimmen und laß die Finger von 'fstrim' ;)
HTH, -dnh
Ist es wirklich so schwer zu begreifen dass die staendig zitierte "failed"-Meldung vom Kernel lediglich bedeutet dass er danach keinen queued trim mehr ausfuehrt sondern einen Fallback auf "normalen" trim macht. Es GIBT KEIN TRIM-PROBLEM MIT DIESER PLATTE. Die Kernel-Meldung ist eine Information, kein Indikator fuer ein zukuenftig auftretendes Problem. Der Blacklist Eintrag fuehrt nur dazu dass die Meldung nicht mehr ausgegeben wird, aber der beim Trim ausgefuehrte Code ist in beiden Faellen praktisch der gleiche. Hier wird die Meldung ausgegeben (libata-core.c): if ((ap->flags & ATA_FLAG_FPDMA_AUX) && ata_id_has_ncq_send_and_recv(dev->id)) { err_mask = ata_read_log_page(dev, ATA_LOG_NCQ_SEND_RECV, 0, ap->sector_buf, 1); if (err_mask) { ata_dev_dbg(dev, "failed to get NCQ Send/Recv Log Emask 0x%x \n", err_mask); } else { u8 *cmds = dev->ncq_send_recv_cmds; dev->flags |= ATA_DFLAG_NCQ_SEND_RECV; memcpy(cmds, ap->sector_buf, ATA_LOG_NCQ_SEND_RECV_SIZE); if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support \n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; } } } Man sieht hier, wenn die Meldung kommt wird ATA_DFLAG_NCQ_SEND_RECV _nicht_ gesetzt. Kaeme keine "failed" Meldung wuerde der Code-Teil der "ATA_HORKAGE_NO_NCQ_TRIM" ueberprueft ueberhaupt erst durchlaufen. Das bedeutet fuer zukuenftige Samsung-Firmwares die auch nach Kernel-Ansicht korrekt waeren wuerde das Trim Kommando trotzdem nicht queued ausgefuehrt. Egals obs geht oder nicht. Und nun libata-transport.c: static ssize_t show_ata_dev_trim(struct device *dev, struct device_attribute *attr, char *buf) { struct ata_device *ata_dev = transport_class_to_dev(dev); unsigned char *mode; if (!ata_id_has_trim(ata_dev->id)) mode = "unsupported"; else if (ata_dev->horkage & ATA_HORKAGE_NOTRIM) mode = "forced_unsupported"; else if (ata_dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) mode = "forced_unqueued"; else if (ata_fpdma_dsm_supported(ata_dev)) mode = "queued"; else mode = "unqueued"; return snprintf(buf, 20, "%s\n", mode); } Und libata.h: static inline bool ata_fpdma_dsm_supported(struct ata_device *dev) { return (dev->flags & ATA_DFLAG_NCQ_SEND_RECV) && (dev->ncq_send_recv_cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] & ATA_LOG_NCQ_SEND_RECV_DSM_TRIM); } Hier wird ausgegeben wie das nun mit dem trim tatsaechlich ist. Im Fall von "kein Samsung in der Blacklist" in dem die "failed"-Meldung kommt wird kein ATA_DFLAG_NCQ_SEND_RECV gesetzt, das bedeutet die Ausgabe (und die Nutzung) ist "unqueued". Im Falle von gesetztem Blacklist-Eintrag kommt "forced_unqueued". UND DAS WARS! Verstanden? -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, kannst du Honk endlich mal damit aufhören, mir Mails zu schreiben und per CC an die Liste? Am Thu, 06 Aug 2015, Stephan von Krawczynski schrieb: [..]
Hier wird die Meldung ausgegeben (libata-core.c):
if ((ap->flags & ATA_FLAG_FPDMA_AUX) && ata_id_has_ncq_send_and_recv(dev->id)) { err_mask = ata_read_log_page(dev, ATA_LOG_NCQ_SEND_RECV, 0, ap->sector_buf, 1); if (err_mask) { ata_dev_dbg(dev, "failed to get NCQ Send/Recv Log Emask 0x%x \n", err_mask);
Und du kapierst nicht, daß es nicht um die Fehlermeldung geht, sondern um die geschredderten Daten!
} else { u8 *cmds = dev->ncq_send_recv_cmds;
dev->flags |= ATA_DFLAG_NCQ_SEND_RECV; memcpy(cmds, ap->sector_buf, ATA_LOG_NCQ_SEND_RECV_SIZE);
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support \n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; } } }
Man sieht hier, wenn die Meldung kommt wird ATA_DFLAG_NCQ_SEND_RECV _nicht_ gesetzt.
Und wozu sind dann die Zeilen
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support\n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; }
Na? Und womit erklärst du den Betroffenen die geschredderten Daten? -dnh -- [Am Tag nach Fukushima] sagte Merkel wörtlich: "Man kann an so einem Tag nicht sagen, daß die Atomkraftwerke sicher sind. Sie sind sicher." [..] Es gibt nur zwei Menschen in diesem Land, die sich in ein und demselben Satz selbst wider- sprechen dürfen, Merkel und Beckenbauer. -- Volker Pispers, Bis neulich 2014 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Thu, 6 Aug 2015 12:27:43 +0200 David Haller <dnh@opensuse.org> wrote:
Hallo,
kannst du Honk endlich mal damit aufhören, mir Mails zu schreiben und per CC an die Liste?
Kannst Du endlich mal mit Deinen staendigen persoenlichen Beschimpfungen aufhoeren? Sowas wie Manieren und normalen Umgang kennst DU wohl nicht?
Am Thu, 06 Aug 2015, Stephan von Krawczynski schrieb: [..]
Hier wird die Meldung ausgegeben (libata-core.c):
if ((ap->flags & ATA_FLAG_FPDMA_AUX) && ata_id_has_ncq_send_and_recv(dev->id)) { err_mask = ata_read_log_page(dev, ATA_LOG_NCQ_SEND_RECV, 0, ap->sector_buf, 1); if (err_mask) { ata_dev_dbg(dev, "failed to get NCQ Send/Recv Log Emask 0x%x \n", err_mask);
Und du kapierst nicht, daß es nicht um die Fehlermeldung geht, sondern um die geschredderten Daten!
Dazu sollte man vielleicht mal nach einer Ursache suchen, und nicht nur offensichtlich falschen Unsinn verbreiten.
} else { u8 *cmds = dev->ncq_send_recv_cmds;
dev->flags |= ATA_DFLAG_NCQ_SEND_RECV; memcpy(cmds, ap->sector_buf, ATA_LOG_NCQ_SEND_RECV_SIZE);
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support \n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; } } }
Man sieht hier, wenn die Meldung kommt wird ATA_DFLAG_NCQ_SEND_RECV _nicht_ gesetzt.
Und wozu sind dann die Zeilen
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support\n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; }
Na?
Weisst Du was ein "if"-Statement ist? Du schreibst Zeug das einen schliessen laesst Du haettest noch keine einzige Zeile programmiert. Wenn die Meldung ueber die man sich aufregte kommt wird dieser Code _nicht_ durchlaufen. Wie aber spaeter zu sehen spielt das keine Rolle weil eben auch ATA_DFLAG_NCQ_SEND_RECV nicht gesetzt wurde.
Und womit erklärst du den Betroffenen die geschredderten Daten?
Vielleicht sollte man mal genau zerlegen was die Daten wirklich zerstoert hat, wenn es denn so ist. Denn bei mir - ich habe ca 50 solche Platten im staendigen Einsatz - ist das noch kein einziges Mal vorgekommen. Wasimmer es war, der Blacklist-Eintrag aendert nichts am Laufzeitverhalten. Vielleicht waere es schlauer nach Parallelen bei den Leuten mit Problemen zu suchen, denn die Zahl der verkauften Platten dieses Typs duerfte die Zahl der gemeldeten und nachvollziehbaren Probleme bei weitem uebersteigen. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Thu, 06 Aug 2015, Stephan von Krawczynski schrieb:
David Haller <dnh@opensuse.org> wrote:
kannst du Honk endlich mal damit aufhören, mir Mails zu schreiben und per CC an die Liste?
Kannst Du endlich mal mit Deinen staendigen persoenlichen Beschimpfungen aufhoeren?
Nicht, solange du nicht mit unnötigen Kopien und sonstigem Schwachsinn aufhörst. Hast du jetzt aber immerhin mal geschafft *Eine Runde Applaus bitte* Hörr Krawallczynski hat es geschafft, auf eine Mail zu antworten, ohne eine PM an den Schreiber zu schicken! *tötööötötööö*
Sowas wie Manieren und normalen Umgang kennst DU wohl nicht?
Doch, durchaus. Nur _dir_ gegenüber nicht. Frag dich mal warum wohl.
Am Thu, 06 Aug 2015, Stephan von Krawczynski schrieb: [..]
Hier wird die Meldung ausgegeben (libata-core.c):
if ((ap->flags & ATA_FLAG_FPDMA_AUX) && ata_id_has_ncq_send_and_recv(dev->id)) { err_mask = ata_read_log_page(dev, ATA_LOG_NCQ_SEND_RECV, 0, ap->sector_buf, 1); if (err_mask) { ata_dev_dbg(dev, "failed to get NCQ Send/Recv Log Emask 0x%x \n", err_mask);
Und du kapierst nicht, daß es nicht um die Fehlermeldung geht, sondern um die geschredderten Daten!
Dazu sollte man vielleicht mal nach einer Ursache suchen, und nicht nur offensichtlich falschen Unsinn verbreiten.
ES GEHT NICHT UM DIE FEHLERMELDUNG!
} else { u8 *cmds = dev->ncq_send_recv_cmds;
dev->flags |= ATA_DFLAG_NCQ_SEND_RECV; memcpy(cmds, ap->sector_buf, ATA_LOG_NCQ_SEND_RECV_SIZE);
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support \n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; } } }
Man sieht hier, wenn die Meldung kommt wird ATA_DFLAG_NCQ_SEND_RECV _nicht_ gesetzt.
Und wozu sind dann die Zeilen
if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM) { ata_dev_dbg(dev, "disabling queued TRIM support\n"); cmds[ATA_LOG_NCQ_SEND_RECV_DSM_OFFSET] &= ~ATA_LOG_NCQ_SEND_RECV_DSM_TRIM; }
Na?
Weisst Du was ein "if"-Statement ist? Du schreibst Zeug das einen schliessen laesst Du haettest noch keine einzige Zeile programmiert.
Doch, hab ich durchaus.
Wenn die Meldung ueber die man sich aufregte kommt wird dieser Code _nicht_ durchlaufen.
ES GEHT NICHT UM DIE FEHLERMELDUNG, DUMPFBACKE! Die hat nur geholfen, den Ort des Fehlers einzugrenzen... *Gnanaaa*
Und womit erklärst du den Betroffenen die geschredderten Daten?
Vielleicht sollte man mal genau zerlegen was die Daten wirklich zerstoert hat, wenn es denn so ist. Denn bei mir - ich habe ca 50 solche Platten im staendigen Einsatz - ist das noch kein einziges Mal vorgekommen.
Ach, du willst uns also erzählen, du hast ca. 50 Samsung 840*/850* SSDs im Einsatz? Erlaube mir hier gewisse Zweifel anzumelden ... Und daß du eh immer von "Platten" faselst... Also wirklich! Das geht ja gar nicht! (*scnr*)
Wasimmer es war, der Blacklist-Eintrag aendert nichts am Laufzeitverhalten.
Nu freilich nich, das ist ja der Sinn und Zweck dieses Eintrages!
Vielleicht waere es schlauer nach Parallelen bei den Leuten mit Problemen zu suchen, denn die Zahl der verkauften Platten dieses Typs duerfte die Zahl der gemeldeten und nachvollziehbaren Probleme bei weitem uebersteigen.
... ich geh mal davon aus, daß du bei Samsung angestellt bist. Case closed. Danke vielmals, und jetzt halte einfach deine Fresse. Was du, genau wie die bei Samsung einfach nich kapieren wollen: Wenn die Firmware darüber lügt was sie kann (hier: behaupten sie könnte NCQ'd TRIM Befehle), dann ist das ein Bug in der Firmware. PUNKT! AUS! UND FINITO! Da gibt's keine Diskussion, da kann man sich nicht rausreden, auch wenn man nen Handstand macht, mit 30 Zehen wackelt oder sich sonst wie zum Affen (Ups: Sorry an alle Affen, ist nur so'n blöder Ausdruck von uns auch-Affen!) macht! Entweder wird das in nem FW-Update implementiert oder eben es gibt ein Update, das der FW beibringt nicht zu lügen. Meine 830 behauptet es z.B. noch nicht. WIMRE war's Dingens (Byte?) 77, Bit 6: ==== smartctl --identify=w /dev/sda ==== 76 1 1 SATA Gen1 signaling speed (1.5Gb/s) supported 77 - 0x0004 Serial ATA additional capabilities 77 3:1 0x2 Current Serial ATA signal speed 78 - 0x004c Serial ATA features supported [..] ==== Die 840 (nur mit aktueller FW[0])/850 behaupten hingegen TRIM via NCQ zu können, tun's aber nicht, schreddern dabei Daten und Holla-di-Waldfee, der User freut sich nen Ast ... NOT! Du findest genug Beispiele im Netz bzgl. geschredderter Daten. Und bei so einem Bug ist _EIN_ betroffener User schon zuviel. Halt also einfach die Fresse, auch wenn du Kohle von Samsung kassieren solltest. Mir egal. Einfach nur die Fresse halten. -dnh [0] die alte hatte diesen Bug noch nicht -- Die Vögelein und die Menschelein haben so viel gemeinsam. wenn sie jeder ein paar Körnchen zu sich nehemen, fangen sie sehr bald an zu singen. [Woko° in dag°] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.08.2015 um 05:05 schrieb David Haller:
Am Wed, 05 Aug 2015, Peter Mc Donough schrieb:
... Du könntest probieren:
zcat /boot/vmlinuz-$VERSION | strings | grep 'Samsung SSD', das klappt aber nicht bei jedem Kernel.
Nix gefunden.
... Wenn du auf Nummer sicher gehen willst, schalt NCQ komplett ab:
libata.force=noncq
Werde ich bei Backups mit dem Rescue-ISOdisks mit Kernel < 4.1x und der SSD beherzigen. Zwischenzeitlich habe ich den 4.1x aus dem stable Repo installiert, läuft gut. Weiterhin habe ich eine Version der Rescue-ISO von Tumbleweed gezogen. Die müssten mindestens den 4.1 Kernel haben, sie hat wohl ein spezielles Festure, mein Rechner bleibt beim Hochfahren hängen. Da werde ich noch herausfinden müssen, woran das liegt. Ideal wäre ein Script, welches aus einer bestehenden Installation ein Rescue-iso erzeugt, mit dem aktuellen Kernel. Es gibt dazu einige Anleitungen bei Google. Gruß Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
David Haller -
Peter Mc Donough -
Stephan von Krawczynski