[EMAIL PROTECTED] wrote: > On Mon, Nov 03, 2008 at 12:33:52PM -0600, Bob Friesenhahn wrote: >> On Mon, 3 Nov 2008, Robert Milkowski wrote: >>> Now, the good filter could be to use MAGIC numbers within files or >>> approach btrfs come up with, or maybe even both combined. >> You are suggesting that ZFS should detect a GIF or JPEG image stored >> in a database BLOB. That is pretty fancy functionality. ;-) > > Maybe some general approach (not strictly GIF- or JPEG-oriented) > could be useful. > > Give people a choice and they will love ZFS even more.
But what is the choice you guys are asking for ? You can already control the compression setting on a per dataset basis what more do you really need ? Remembering that the more knobs there are to turn the harder it is to reason about what is going on and predict behaviour. I just don't see what the problem is with the current situation. You either want compression or you don't, this works at the block level in ZFS and it already has checks and balances in place to ensure that it doesn't needlessly burn CPU (decompression is usually what is more expensive than compression). Can someone who cares about this put a proposal together to show what this would look like from a ZFS properties view and what it would actually do, because I'm not getting it. -- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
