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/[email protected] compressratio 1.91x -
> storage/compressed/[email protected] compressratio 1.91x -
> storage/compressed/[email protected] compressratio 1.91x -
> storage/compressed/[email protected] compressratio 1.91x -
> storage/compressed/bacula AT pre DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
