IRC Logs for #lost


2021-04-09

07:14:15 XanClic joined the channel
08:36:22 kevin joined the channel
10:19:02 kevin: XanClic: Ich glaube, es gab einen Grund, warum mirror_complete() ein paar Sachen vorher macht
10:19:10 XanClic: schade
10:19:14 kevin: Nicht, dass ich noch wüsste, welcher das ist, und ob er immer noch gilt...
10:19:39 kevin: Erstmal was essen, aber ich kann mir nachher mal den Code anschauen, ob es mir wieder einfällt
10:19:46 XanClic: Guten
10:19:48 kevin: Danke
10:20:42 XanClic: (Wenn ich mir 737efc1eda2 so ansehe, sieht es so aus, als wäre .exit einfach eine void-Funktion gewesen, und deshalb wollte man in .complete ein bisschen was vorbereiten, wo man tatsächlich noch Fehler anzeigen kann)
10:21:05 XanClic: (Ach, nein, job->ret setzen ging ja.)
10:28:39 XanClic: (vielleicht, weil @replaces by block-job-complete aufgelöst werden soll und nicht erst später, aber das könnte man definitiv auch machen während der Job pausiert ist)
10:52:23 kevin: Hm, das mit dem Fehler könnte natürlich sein, damit man Error statt int hat
10:53:18 XanClic: Ich würd sagen, man kann den MIRROR_OPEN_BACKING_CHAIN-Block nach mirror_exit_common() verschieben, denn da wird ja auch MIRROR_SOURCE_BACKING_CHAIN abgehandelt
10:53:46 XanClic: Der Teil mit to_replace ist eigentlich egal, wo der ausgeführt wird, das ist keine Graphänderung, werden ja nur Blocker gesetzt
10:53:53 XanClic: Und dann sollte das eigentlich schon fertig sein
10:55:02 kevin: Ich finde dein Argument schon richtig, dass man replaces in job-complete auflösen muss, von daher macht es einen Unterschied, wo es ausgeführt wird
10:55:14 XanClic: Ja, das kann von mir aus auch da bleiben
10:55:16 kevin: Aber bdrv_op_block_all() und bdrv_ref() sind harmlos
10:56:46 kevin: Ja, von mir aus dann auch so
10:58:38 kevin: Es fixt natürlich immer noch nur den einen Fall, den wir halt kennen
10:58:54 XanClic: Ja
10:59:21 kevin: Someone™ müsste mal schauen, ob automatisch pausierte Jobs noch woanders Probleme machen könnte
10:59:33 XanClic: Haben wir nicht Maintainer für die Jobs? :)
10:59:51 kevin: Hat sich nicht Vladimir kürzlich in MAINTAINERS eingetragen? :-)
10:59:57 XanClic: Oh, ich glaube schon O:)
11:00:19 XanClic: Na ja, wenn man was mit drained_end macht, hab ich immer noch nicht ganz verstanden, warum man dann auf alle Jobs warten sollte, muss ich sagen
11:00:42 XanClic: Von mir aus kann man mit drained_end_counter darauf warten, dass Jobs, die tatsächlich für Resume geschedulet sind, auch resumet wurden
11:00:42 kevin: Auf alle Jobs oder auf alle Drains?
11:01:13 XanClic: Aber ich hab nicht verstanden, warum man auch auf Jobs warten sollte, die zwar von der Sektion erfasst wurden, aber von einem anderen Drain noch pausiert werden
11:02:06 kevin: Hm, wahrscheinlich ist Jobs drainen in einem iothread sowieso kaputt
11:03:14 kevin: In der Zeit, in der der Job gedraint ist, kann ja trotzdem der Mainloop-Thread was damit zu machen versuchen (vor allem halt QMP)
11:03:52 kevin: Und der AioContext ist nicht durchgehend gelockt, vor allem solange drained_begin pollt
11:06:51 kevin: Insofern würde auf andere Drains in diesem Kontext einen Bug fixen, den es sonst immer noch gibt. Also ist das auch schon egal.
11:07:06 kevin: Weil der Fall, in dem es den Bug noch gibt, der viel häufigere ist
11:07:24 kevin: *auf andere Drains warten
11:08:06 XanClic: warum ist eigentlich immer alles so kaputt
11:08:13 kevin: Also ja, mit dem Argument "eh alles kaputt" kann man auch einfach nur auf die Jobs warten, die tatsächlich für Resume geschedult sind
11:09:34 kevin: XanClic: Ich bin mir sicher, das hat ganz bestimmt nichts mit uns zu tun ;-)
11:09:41 XanClic: Natürlich nicht
11:09:52 XanClic: das ist doch alles noch Fabrice’ Code, bin ich mir sicher
11:11:31 kevin: Ganz bestimmt. Oder zumindest logische Folge davon.
14:26:28 kevin: XanClic: Welche Version findest du schöner?
14:26:51 XanClic: Eigentlich die, die mirror verändert, weil man da ja dann ganz ohne Warten auskommt
14:27:09 kevin: Ok, sehe ich auch eher so
14:27:14 XanClic: Und man braucht keinen Followup-Patch, der block-job-complete coroutine_fn macht
14:27:42 kevin: Zwar nicht wegen dem Warten, sondern eher wegen dem Fehlerfall. Genau der.
14:28:05 kevin: Aber nicht warten ist natürlich auch gut
15:20:48 kevin: XanClic: Warum muss der iotest denn so viel I/O machen? Ist das, damit das drain lang genug dauert?
15:22:31 XanClic: kevin, die Idee war, damit die I/O-Jobs so viel zu tun haben, dass einmal rein-job_enter()-n ein bisschen dauert
15:22:51 XanClic: Sodass das eine Weile dauert, bis alle angelaufen sind
15:23:18 XanClic: Aber ganz ehrlich, ich hab einfach rumprobiert und irgendwann wars kaputt und ich war glücklich
15:23:38 kevin: Was wahrscheinlich ein bisschen ungünstig ist, ist, dass wir block-job-complete erst senden, wenn die Antwort für transaction da ist
15:23:54 XanClic: In meinem Rubyscript hab ichs vorher geschickt
15:23:59 XanClic: Also direkt hintereinander, ohne auf die Antwort zu warten
15:24:04 XanClic: Aber so richtig besser geholfen hats auch nicht
15:24:05 kevin: Macht keinen Unterschied?
15:24:06 XanClic: Insofern
15:24:08 kevin: Hm, ok
15:25:07 kevin: Also bei mir ist der Test auch so schnell genug, aber er will nicht failen
15:25:33 XanClic: Auf NVMe geht er so 15/100 kaputt
15:25:42 XanClic: Denke mal, auf Festplatten wärs am besten, aber na ja…
15:25:58 kevin: Ah, jetzt, Schleife lang genug laufen lassen, dann passiert es mal
15:26:35 kevin: I/O teuer machen (also Throttling) können wir, wenn das hilft
15:27:01 XanClic: Hab ich nicht probiert, weil ich dachte, das würde dann doch nur yielden
15:27:06 XanClic: Aber vielleicht lag ich da falsch
15:27:13 XanClic: Also dass dann halt der nächste Job resumet wird
15:29:08 kevin: Stimmt auch wieder, das hält den BH nicht davon ab, ausgeführt zu werden
15:29:17 kevin: Aber wieso denkst du dann, dass es auf Festplatten besser wäre?
15:30:13 XanClic: Gute Frage eigentlich
15:30:19 XanClic: ist ja trotzdem async-I/O
15:30:25 XanClic: Dann wohl nicht
15:38:25 kevin: Hm. Gut, dann ist der Test halt so wie er ist. Gute Frage, ob das sinnvoll ist, den zu mergen oder nicht.
15:39:06 kevin: Eigentlich dupliziert er ja nur, was der Unittest schon macht, oder?
15:56:07 XanClic: Eigentlich schon, ja
15:56:36 XanClic: deshalb hab ich ihn in v1 auch nicht mitgeschickt
15:56:52 XanClic: Aber Vladimir hat nunmal gefragt, ob man das auch von außen sieht, und da dachte ich, vielleicht ists doch ganz nett, zu zeigen, dass ja
19:48:12 Paddy joined the channel