On (23/08/07 14:44), Ian Wienand wrote: [..] > > At this point, because this test fills from /dev/zero, the zsmalloc > pool doesn't actually have anything in it. The filesystem metadata is > in-use from the writes, and is not written out as compressed data. > The zram page de-duplication has kicked in, and instead of handles to > zsmalloc areas for data we just have "this is a page of zeros" > recorded. So this is correctly reflecting that fact that we don't > actually have anything compressed stored at this time. > > > >> If we do a "sync" then redisply the mm_stat after, we get > > >> 26214400 2842 65536 26214400 196608 399 0 0 > > Now we've finished writing all our zeros and have synced, we would > have finished updating vfat allocations, etc. So this gets compressed > and written, and we're back to have some small FS metadata compressed > in our 1 page of zsmalloc allocations. > > I think what is probably "special" about this reproducer system is > that it is slow enough to allow the zero allocation to persist between > the end of the test writes and examining the stats. > > I'd be happy for any thoughts on the likelyhood of this! Thanks for looking into this. Yes, the fact that /dev/urandom shows non-zero values in mm_stat means that we don't have any fishy going on in zram but instead very likely have ZRAM_SAME pages, which don't reach zsmalloc pool and don't use any physical pages. And this is what 145 is in mm_stat that was posted earlier. We have 145 pages that are filled with the same bytes pattern: > > >> however, /sys/block/zram1/mm_stat shows > > >> 9502720 0 0 26214400 196608 145 0 0 > If we think this is right; then the point of the end of this test [1] > is ensure a high reported compression ratio on the device, presumably > to ensure the compression is working. Filling it with urandom would > be unreliable in this regard. I think what we want to do is something > highly compressable like alternate lengths of 0x00 and 0xFF. So var-lengths 0x00/0xff should work, just make sure that you don't have a pattern of sizeof(unsigned long) length. I think fio had an option to generate bin data with a certain level of compress-ability. If that option works then maybe you can just use fio with some static buffer_compress_percentage configuration.
