07:22:05 XanClic joined the channel
07:52:05 kevin joined the channel
13:42:10 kevin: XanClic: Willst du für die TRIM-vs.-Drain-Sache mal versuchen, das Queuing in blk_drain_all() temporär zu deaktivieren? Oder haben wir im Moment einen anderen Vorschlag?
13:42:20 kevin: Weil du hast das ja for-8.0 markiert und morgen ist schon -rc2
13:42:36 XanClic: So richtig hatte ich nicht das Gefühl, dass das noch für 8.0 reichen wird
13:42:49 XanClic: Der andere Vorschlag war ja nur, alle Discards gleichzeitig zu submitten
13:42:57 XanClic: Kann gern beides probieren
13:43:25 kevin: Wie wahrscheinlich ist es denn, da reinzulaufen?
13:43:36 kevin: Wenn wir es nicht für 8.0 brauchen, ist es natürlich entspannter
13:43:41 XanClic: Na ja, es ist IDE…
13:43:51 XanClic: Und dann muss man ein TRIM über IDE machen…
13:43:57 XanClic: Über DMA
13:44:24 XanClic: ich wusste bis zu dem ursprünglichen Bug gar nicht, dass es TRIM über IDE mit DMA-übertragenen Sektorlisten überhaupt gibt
13:44:34 kevin: :-)
13:44:47 kevin: Und dann gleichzeitig auch noch ein Reset auslösen, oder wie war das?
13:44:48 XanClic: An sich reicht glaub ich jedes Drain während so eines TRIMs
13:44:56 XanClic: Ja, ein Reset würde zum Beispiel ein Drain auslösen
13:45:26 kevin: Ich glaube, ein Reset außerhalb von IDE wäre kein Problem, dann wäre der Request halt gequeuet und gut
13:45:53 kevin: Oder übersehe ich da was?
13:46:07 XanClic: Fiona hat das ja mit Drain wegen blockdev-backup gefunden
13:46:45 XanClic: Das gesamte Trim hat einen In-Flight-Count, und dann jedes Discard darin noch einen
13:47:17 XanClic: drain_begin wird dann das laufende Discard beenden, aber wenn das Trim dann noch eins starten möchte, dann wird dieses nächste eben gequeuet
13:47:40 XanClic: Und dann wartet Trim auf das gequeute Discard, das nie wirklich läuft, und drain_begin wartet immer noch auf das Trim an sich
13:48:13 XanClic: Also eigentlich jedes Drain, solange die Trim-Liste noch mindestens ein weiteres nicht submittetes Discard anzeigt
13:48:57 kevin: Ach richtig, weil IDE selber ein blk_inc_in_flight() macht, sonst wüsste Drain nichts vom Trim
13:49:33 XanClic: Ja, das Problem da war halt, wenn Drain nichts vom Trim weiß, dann macht es auch nix, wenn kein Discard mehr ansteht, sondern nur noch die beendende BH geschedulet ist
13:50:34 kevin: Das war dann der andere Commit, der das hier kaputtgemacht hat?
13:50:37 XanClic: Und dann wird Discard also nicht wirklich das ganze Trim beenden, was blöd ist, weil mindestens ide_cancel_dma_sync() das so annimmt
13:50:38 XanClic: ja
13:52:41 XanClic: Da der In-Flight-Counter von TRIM im BB ist, sollte das funktionieren, wenn man Request-Queuing in blk_drain*() deaktiviert, ja
13:52:57 XanClic: Weil bdrv_drain*() sich nicht am Trim aufhängen wird (denke ich…)
13:53:04 kevin: Eine andere Idee, die wir letzte Woche im Multiqueue-Call angekratzt haben, wäre, dass BlockdevOps einen Callback kriegt, wenn ein Request gequeuet wird und wenn er weiterläuft. Dann könnte IDE da solange ein dec_in_flight() machen.
13:53:32 XanClic: Aber Paolo meinte doch, dass es wichtig ist, dass das Trim von einem blk_drain* wirklich vollständig beendet wird, oder nicht?
13:53:38 kevin: Wir haben das im Kontext von Exports diskutiert, die haben anscheinend das gleiche Problem
13:53:38 XanClic: Damit es zum Beispiel vor einer Migration vollständig beendet ist
13:54:06 kevin: Bei einem blk_drain_all(), aber nicht unbedingt bei einem bdrv_drained_begin/end()
13:54:16 kevin: Das sind die zwei verschiedenen Drain-Arten, die ich erwähnt habe
13:54:29 kevin: Also einmal ich will den Knoten exklusiv, und einmal ich will auf alle meine Requests warten
13:55:17 kevin: Das müsste vermutlich man zusammen mit dem temporären Deaktivieren von Queuing in blk_drain_all() machen
13:55:34 XanClic: Dann würde das aber IDE nicht unmittelbar betreffen, oder?
13:55:46 XanClic: Weil das Trim ja eben nur im BB ist und deshalb für bdrv_drain* sowieso keine Auswirkungen haben sollte
13:56:07 XanClic: Es sei denn, bdrv_drain* queriet die Eltern und wartet so doch irgendwie wieder auf den BB-In-Flight-Counter…
13:56:27 kevin: bdrv_drain*() ruft halt die Drain-Callbacks im Parent auf
13:56:34 kevin: Genau
13:57:35 XanClic: Aber wenn ich für die bdrv_drain-Funktionen weiter Request Queuing im BB aktiviert lasse, kann ich dann nicht einfach den In-Flight-Counter im BB ignorieren?
13:58:44 kevin: Hm, wieso? Das Queuing sorgt ja nur dafür, dass in_flight auf 0 geht, aber wenn Dinge nicht gequeuet sind, muss ich auf die doch trotzdem warten?
13:58:57 XanClic: Aber im BB ist es für das BDS doch egal
13:59:26 kevin: Ach so. Hm. Wenn das BB nichts neues mehr schicken kann, dann ist es dem BDS egal, ja.
13:59:26 XanClic: Wenn ich bdrv_drain* benutze und ein BDS gedraint haben möchte, ist doch egal, ob es auf einem Elternknoten noch einen aktiven Request gibt, solange der mir verspricht, keinen Request auf dem BDS, das mich interessiert, auszulösen
13:59:57 XanClic: Nur klingen diese Lösungen alle ein bisschen zu kaputt für rcX mit X ≥ 2 ;)
14:00:02 XanClic: s/kaputt/waghalsig/
14:00:09 kevin: Jo, vermutlich
14:00:48 kevin: Vor allem, wenn der Bug schon ein Jahr lang drin ist
14:01:25 XanClic: Alle Discards gleichzeitig abzuschicken wär also das einzige, was irgendwie möglich erscheinen würde, weil das lokal in IDE eine Änderung wäre
14:01:34 XanClic: Aber auch nicht trivial
14:03:28 kevin: Wie gesagt, Exports haben das gleiche Problem. Ich vermute, dass eine lokale Lösung in IDE nicht das ist, was mal idealerweise haben will.
14:03:31 kevin: *man
14:03:36 XanClic: Vermutlich nicht
14:04:28 XanClic: Ich kann ja mal probieren, was passiert, wenn man Request-Queuing in blk_drain* deaktiviert, und die BB-Node-Parent-Query-Drain-Funktionen ihren In-Flight-Counter ignorieren, wenn Request-Queuing aktiviert ist
14:04:31 XanClic: Wie viele iotests dann kaputtgehen
14:06:37 kevin: Au ja, einfach mal ausprobieren in Sachen wie Drain
14:07:21 XanClic: Ich kann nur sagen, dass das die qsd-rs-Lösung ist
14:07:40 XanClic: Der Elternknoten wird nicht gequiescet, sondern bekommt einfach nur Request-Queuing, bis der Graph-Rekonfiguration durch ist
14:08:47 XanClic: Kann jetzt alles heißen, praktisch heißt es vermutlich nur, dass ich für die Lösung gebiaset bin
14:09:24 XanClic: Eigentlich will ich doch nur einen Patch, den ich Paolo schicken kann, und der sagt mir dann, was kaputt ist.
14:09:39 XanClic: Oder halt du :)
15:24:44 kevin: Letzte Woche habt ihr noch versucht, mir klarzumachen, dass qsd-rs keine echten Vorteile hat ;-)
15:57:12 mib_ucufyv joined the channel
23:56:12 Biolunar joined the channel