08:00:49 XanClic joined the channel
08:59:56 kevin joined the channel
10:06:57 Biolunar joined the channel
14:43:26 kevin: XanClic: Oooh, Streaming geht deswegen nicht kaputt, weil es buffer_is_zero() prüft und dann write_zeroes macht. Sag das doch gleich. :-)
14:43:50 XanClic: Wie… praktisch
14:43:54 kevin: Genau *g*
14:44:05 kevin: Das andere Wort, an das ich dachte, ist kaputt
14:44:14 kevin: Aber funktionierend kaputt!
14:44:16 XanClic: Wollte Nir tatsächlich schon fast vorschlage, detect-zeroes=true zu setzen
14:44:28 XanClic: Vielleicht hätt ihm das ja was gebracht
14:45:30 kevin: Der ganze Codepfad ist ein bisschen komisch und ruft mehrere Male bdrv_is_allocated() auf, aber wenn das eh nichts tut und das Ergebnis trotzdem irgendwie tut...
14:46:03 kevin: Ich weiß zwar nicht, was so schlimm daran wäre, einen bool mehr zu speichern und zu vergleichen, aber ich fürchte, dann habe ich kein praktisch relevantes Argument mehr ;-)
14:48:54 XanClic: Eigentlich nichts, aber es wär ein leicht größeres Diff ;)
14:49:41 XanClic: Mir fällt halt so Zeug ein wie: Dann würde ja ein want_zero=false ein vorheriges want_zero=true-Ergebnis überschreiben, was irgendwie schade ist, weil wie den BSC ja eben eigentlich nur für want_zero=true brauchen
14:50:17 XanClic: andererseits hab ich nicht das Gefühl, dass gemixte want_zero=true- und -false-Calls irgendwie performancemäßig relevant sind
14:50:47 XanClic: Irgendwie einfach alles nichts, worüber ich unbedingt vor heute morgen nachdenken wollte *g*
14:52:54 kevin: *g*
14:53:45 kevin: Naja, der Fall, wo der Cache relevant ist, sind ja so Sachen, wo man eine große Schleife hat und ständig neu abfragt. Und das dürfte immer mit demselben want_zero-Wert sein.
14:54:19 kevin: Aber du hast schon recht, wenn der Blocktreiber da dann eh nichts macht, ist es auch gleich wurscht
14:54:59 kevin: Vielleicht hätte man is_allocated dann nur nicht in block_status integrieren sollen, wenn man am Ende sowieso fast alles unterschiedlich macht
14:55:27 kevin: Kann man sich dann ja überlegen, wenn sowas in einem qsd-rs ansteht ;-)
14:55:31 XanClic: Au ja
15:14:46 kevin: Hm, aber sollte COR trotzdem lieber block_status benutzen? Weil gigabyteweise Buffer memsetten und nachher prüfen ob sie wirklich nur Nullen enthalten, ist ja auch ein bisschen doof...
15:15:55 XanClic: „Warum nicht?“ sind schon verfluchte Worte, oder?
15:16:07 kevin: Weiß nicht :-)
15:16:40 kevin: Oh, es ist ja in QEMU gar kein memset(). Das sind richtige Reads und der Kernel füllt dann mit Nullen. Das kann nicht viel schneller sein als das lseek(), das wir damit wegoptimieren wollten...
15:17:01 XanClic: Na ja. Das war ja immer die Frage, dachte ich
15:17:13 XanClic: dass lseek() gerade auf tmpfs langsam war, aber read halt schon fast schneller
15:17:43 kevin: War da read() wirklich schneller als lseek()?
15:17:44 XanClic: und auf jeden Fall, wenn es nur um kleine Nullbereiche ging
15:17:58 XanClic: möglicherweise, aber andererseits haben wir jetzt halt auch den Cache
15:18:13 XanClic: eigentlich sollte ja jetzt nichts mehr gegen volles block-status sprechen
15:18:14 kevin: Hm, auf tmpfs deswegen, weil der Kernel dann halt auch nur buffer_is_zero() macht?
15:18:33 XanClic: könnte fast sein
15:18:52 XanClic: ich weiß nur, dass das irgendwie lineare Laufzeit (abhängig von ftell()) hatte
15:19:01 XanClic: warum, keine Ahnung
15:19:11 kevin: Vermutlich will man das gar nicht so genau wissen
15:19:21 XanClic: also ich wollte es offensichtlich nie so genau wissen *g*
15:20:20 kevin: tmpfs lebt doch eigentlich nur im Page Cache, oder? Und dann weiß ich sicher, dass ich es nicht genauer wissen möchte ;-)
15:21:09 XanClic: Au, stimmt, das macht doch sicher nur buffer_is_zero() pro Page :/
15:21:32 kevin: Wenn die Page vorhanden ist zumindest
15:21:42 kevin: Also SEEK_DATA müsste schneller gehen?
15:22:25 XanClic: wobei auch nicht ganz klar wäre, wieso das dann O(ftell()) ist
15:22:37 XanClic: Und nicht O(seek_ergebnis - ftell())
15:22:46 kevin: Stimmt
15:22:48 XanClic: vielleicht hab ich auch was falsch verstanden
15:23:01 kevin: Oder es ist einfach noch kaputter als wir uns das vorstellen
15:23:10 XanClic: Unknown unknowns?
15:23:17 kevin: Irgendwie sowas
15:23:27 kevin: Aber wie auch immer, wenn wir cachen, dürfte es ja eh nicht mehr so schlimm sein
15:23:48 XanClic: eigentlich™ machen wir das ja dafür, ja
15:24:42 kevin: Und dann brauchen wir auch nicht den Codepfad fixen, der gefühlt fünfmal prüft, ob der Bereich wirklich nicht alloziert ist *g*
15:26:58 XanClic: vielleicht sollten wir einfach so lange prüfen, bis es nicht alloziert ist
15:31:01 kevin: Klingt gut
15:31:08 kevin: Und der Ansatz lässt sich doch sicher verallgemeinern
15:46:02 XanClic: klar, einfach qemu-img convert durch qemu-img compare ersetzen und warten, bis kosmische Strahlung das gewünschte Ergebnis erzeugt hat :)
15:52:02 kevin: Man reiche mir die nichtdeterministische Turingmaschine
21:23:00 Paddy joined the channel