From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- results/classifier/gemma3:12b/files/498523 | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 results/classifier/gemma3:12b/files/498523 (limited to 'results/classifier/gemma3:12b/files/498523') diff --git a/results/classifier/gemma3:12b/files/498523 b/results/classifier/gemma3:12b/files/498523 new file mode 100644 index 00000000..3890f9c8 --- /dev/null +++ b/results/classifier/gemma3:12b/files/498523 @@ -0,0 +1,8 @@ + +Add on-line write compression support to qcow2 + +This is a wishlist item. Launchpad really need a way for the submitter to indicate this. + +It would be really cool if qemu were to support disk compression on-line for writes. + +I know this wouldn't be really easy. Although most OS's use blocks, you can really only count on being able to compress 512-byte sectors, which doesn't give much room for a good compression ratio. Moreover, the index indicating where in the image file each sector is located would be complex to manage, since the compressed blocks would be variable sized, and you'd be wanting to do some kind of best-fit allocation of space in the image file. (If you were to make the image file compressed block size granularity, say, 64 bytes, you could probably do this best fit O(1).) If you were to buffer enough writes, you could group arbitrary sequences of written sectors into blocks to compress (which with writeback could be sent to a helper thread on another CPU, so the throughput would be good). \ No newline at end of file -- cgit 1.4.1