[systemd-devel] [PATCH] journal, coredump: allow relative values in some configuration options

[Jan Synacek]

Lennart Poettering <lennart at poettering.net> writes:

> Hmm, this doesn't look right. here we choose the hash table sizes to
> use for a file, and I doubt we should base this on the currently
> available disk space, since sizing the hashtable will have an effect
> on the entire lifetime of the file, during which the available disk
> space might change wildly.
>
> I think it would be best not to do relative sizes for the journal file
> max size at all, and continue to only support and absolute value for
> that. 
>
>> +
>> +uint64_t size_parameter_evaluate(const SizeParameter *sp, uint64_t available) {
>> +        if (sp->value == (uint64_t) -1)
>> +                return (uint64_t) -1;
>> +
>> +        if (sp->relative)
>> +                return sp->value * 0.01 * available;
>
> Hmm, so this implements this as percentage after all. as mentioned in
> my earlier mail, I think this should be normalized to 2^32 instead, so
> that 2^32 maps to 100%...

I realized that I got the patch wrong. What I really wanted was to take
percentage values of *disk size*, not available space. Using disk size
would make it constant. Having said that, is it ok to change even the
options that you said were the bad idea? Also, does it really make sense
to implement the relative values as a mapping as you have suggested? To
me it really doesn't, since you can't take more than 100% of disk space
is not possible (I don't really count thin LVs), and mapping to a
huge interval is just not as readable as using percentage. What is the
advantage of the mapping again? Sorry if I'm being thick.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150528/2e5d6128/attachment.sig>