On Jan 20, 2011, at 12:44 PM, Dan Langille wrote: > > On Thu, January 20, 2011 12:28 pm, Silver Salonen wrote: >> On Thursday 20 January 2011 19:02:33 Paul Mather wrote: >>> On Jan 20, 2011, at 11:01 AM, John Drescher wrote: >>> >>>>>> This is normal. If you want fast compression do not use software >>>>>> compression and use a tape drive with HW compression like LTO >>> drives. >>>>>> >>>>>> John >>>>> Not really an option for file/disk devices though. >>>>> >>>>> I've been tempted to experiment with BTRFS using LZO or standard zlib >>>>> compression for storing the volumes and see how the performance >>> compares >>>>> to having bacula-fd do the compression before sending - I have a >>>>> suspicion the former might be better.. >>>>> >>>> >>>> Doing the compression at the filesystem level is an idea I have wanted >>>> to try for several years. Hopefully one of the filesystems that >>>> support this becomes stable soon. >>> >>> I've been using ZFS with a compression-enabled fileset for a while now >>> under FreeBSD. It is transparent and reliable. Looking just now, I'm >>> not getting great compression ratios for my backup data: 1.09x. I am >>> using the speed-oriented compression algorithm on this fileset, though, >>> because the hardware is relatively puny. (It is a Bacula test bed.) >>> Probably I'd get better compression if I enabled one of the GZIP levels. >> >> Isn't the low compression ratio because of bacula volume format that >> "messes up" data in FS point of view? The same thing that is a problem in >> implementing (or using an FS-based) deduplication in Bacula. > > I also use ZFS on FreeBSD. Perhaps the above is a typo. I get nearly 2.0 > compression ratio. > > $ zfs get et compressratio > NAME PROPERTY VALUE SOURCE > storage compressratio 1.89x - > storage/compressed compressratio 1.90x - > storage/compressed/bacula compressratio 1.90x - > storage/compressed/bacula@2010.10.19 compressratio 1.91x - > storage/compressed/bacula@2010.10.20 compressratio 1.91x - > storage/compressed/bacula@2010.10.20a compressratio 1.91x - > storage/compressed/bacula@2010.10.20b compressratio 1.91x - > storage/compressed/bac...@pre.pool.merge compressratio 1.94x - > storage/compressed/home compressratio 1.00x - > storage/pgsql compressratio 1.00x -
Nope, not a typo: backup# zfs get compressratio NAME PROPERTY VALUE SOURCE backups compressratio 1.07x - backups/bacula compressratio 1.09x - backups/hosts compressratio 1.46x - backups/san compressratio 1.06x - backups/san@filedrop compressratio 1.06x - The backups/bacula fileset is where my Bacula volumes are stored. As I surmised, I get better compression ratios under GZIP-9 compression: backup# zfs get compression NAME PROPERTY VALUE SOURCE backups compression off default backups/bacula compression on local backups/hosts compression gzip-9 local backups/san compression on local backups/san@filedrop compression - - (Compression="on" equates to "lzjb," which is the most lightweight method, CPU resources wise, but not the best in terms of compression ratio achieved.) I will probably switch the other filesets to GZIP compression, as ZFS performance has improved significantly under RELENG_8... Cheers, Paul. ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
