On Thu, 6 Aug 2015 05:05:32 +0200 David Haller 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

On Thu, 6 Aug 2015 12:27:43 +0200 David Haller 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

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