On 05/11/2008, at 2:22 PM, Ian Collins wrote: > Bob Friesenhahn wrote: >> On Wed, 5 Nov 2008, David Gwynne wrote: >> >> >>> be done in a very short time. perhaps you can amortize that cost by >>> doing it when the data from userland makes it into the kernel. >>> another >>> idea could be doing the compression when you reach a relatively low >>> threshold of uncompressed data in the cache. ie, as soon as you get >>> 1MB of data in the cache, compress it then, rather than waiting till >>> you have 200MB of data in the cache that needs to be compressed >>> RIGHT >>> NOW. >>> >> >> This is counter-productive. ZFS's lazy compression approach ends up >> doing a lot less compression in the common case where files are >> updated multiple times before ZFS decides to write to disk. If your >> advice is followed, then every write will involve compression, rather >> than the summation of perhaps thousands of writes. >> >> > But gzip has a significant impact when doing a zfs receive. It would > be > interesting to see how an amortised compression scheme would work in > this case. Currently writing to a filesystem with gzip compression > takes more than twice the time than a to one with lzjb compression > on a > quiet x4540. There isn't any noticeable difference between lzjb and > no > compression.
i dont think lzjb needs big memory allocations like gzip does. those memory allocs cause a ton of xcals on a system, which cant be good for interactivity. dlg _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
