On 05/11/2008, at 3:27 AM, 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.
when the compression happens can be an arbitrary line in the sand. on one side of the line you're mitigating compression per write by deferring the compression as long as possible, and on the other side you want to spread the cost of compression out over time to avoid locking up the machine by doing lots of little compressions more often. this is a similar trade off zfs makes with its cache and its flush interval. the flush interval is adjustable in zfs, why cant the "compression interval/watermark" be invented and made adjustable as well? dlg > > > Bob > ====================================== > Bob Friesenhahn > [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
