> Kern Sibbald wrote:
>> On Monday 23 November 2009 19:36:10 Steve Polyack wrote:
>>
>>> Steve Polyack wrote:
>>>
>>>> I've simply added another configuration option for any Storage {}
>>>> resource in the Director's config. An admin may set
>>>> AllowCompression=No for a particular storage resource, causing the
>>>> director to prevent any GZIP compression options from being sent to
>>>> the FD when a job is run against that particular storage resource.
>>>> The default for the directive is Yes/true so that behavior is
>>>> unchanged for anyone who does not choose to set it. There may be a
>>>> better way to strip the compression flags from the fo->opts[] going
>>>> out to the FD, but this works great and appears readable to me.
>>>>
>>>> Any feedback or suggestions would be appreciated. I'd like to see the
>>>> code added to a later version of Bacula.
>>>>
>>> No questions/comments/suggestions/hate mail?
>>>
>>
>> We always appreciate patches :-)
>>
>> As I mentioned on the bacula-devel list, I was on the road last week. I
>> did
>> see your patch but have not worked through the stacked up emails yet.
>>
>> Preliminary remark 1: cleaver idea. Preliminary remark 2: I think some
>> users
>> might be annoyed if compression is turned off with no warning, which
>> would
>> not be too hard to fix.
>>
>> Regards,
>>
>> Kern
>>
>>
> Thanks. I've added a warning to indicate that it's turning off
> compression for the job because the option is set for the particular
> storage resource. I believe I've also introduced a bug which may cause
> future runs of a similar job to run without compression - I've modified
> my patch to send the a new/copied options string instead of modifying
> fo->opts, which I believe will correct the problem.
>
> After some more testing I'll re-submit the patch.
Thanks for making the warning change. Also on the bug, thanks for
catching it, I didn't notice it in the original code :-(
Please try to resubmit as soon as possible (before the end of next week)
we have more or less frozen the feature set because we would like to
release in early January. If we get the patch soon, I can almost
guarantee it will go in (provided no problems show up). After next week,
it will probably need to be held for the next release ...
Per Eric, I'll
> eventually come up with some documentation and regression tests, but it
> may be a while before I can get to them.
The documentation is much less urgent. Generally, we are tweaking it
right up to the last minute.
Best regards,
Kern
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
