svn commit: r316938 - head/sbin/savecore

[Ronald Klop]

On Fri, 14 Apr 2017 22:29:18 +0200, Mark Johnston <markj at freebsd.org>  
wrote:

> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <ngie at freebsd.org> wrote:
>> > Author: ngie
>> > Date: Fri Apr 14 19:41:48 2017
>> > New Revision: 316938
>> > URL: https://svnweb.freebsd.org/changeset/base/316938
>> >
>> > Log:
>> >   savecore: fix space calculation with respect to `minfree` in  
>> check_space(..)
>> >
>> >   - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>> >     representable data to INT_MAX. Check the values received from
>> >     strtoll(3), trimming trailing whitespace off the end to maintain
>> >     POLA.
>> >   - Use `KiB` instead of `kB` when describing free space, total space,
>> >     etc. I am now fully aware of `KiB` being the IEC standard for 1024
>> >     bytes and `kB` being the IEC standard for 1000 bytes.
>> >   - Store available number of KiB in `available` so it can be more
>> >     easily queried and compared to ensure that there are enough KiB to
>> >     store the dump image on disk.
>> >   - Print out the reserved space on disk, per `minfree`, so end-users
>> >     can troubleshoot why check_space(..) is reporting that there isn't
>> >     enough free space.
>> >
>> >   MFC after:    7 weeks
>> >   Reviewed by:  Anton Rang <rang at acm.com> (earlier diff), cem  
>> (earlier diff)
>> >   Tested with:  positive/negative cases (see review); make tinderbox
>> >   Sponsored by: Dell EMC Isilon
>> >   Differential Revision:        D10379
>>
>> The free space calculation is still uselessly conservative, because it
>> doesn't account for the fact that core dumps will always be either
>> spare or compressed.  The result is that savecore will frequently
>> refuse to save corefiles even when there's plenty of space.  I
>> proposed removing the space check altogether in
>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
>> after the compressed core dump feature was merged, because then mostly
>> accurate space checks will be possible.  AFAIK the compressed core
>> dump feature still hasn't been finished.
>
> I had held off on it for a while because it was going to conflict with
> the work to add encrypted dump support, which of course has finished.
>
> The patch to add compression support is here and should largely still
> work:
> https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_dump.diff
>
> I've been hesitant about pushing it forward:
> - The dump_write* APIs need some simplification after the addition of
>   encrypted dump support and support for dumping to 4Kn drives.
> - I'm not sure how encryption should compose with compression. It seems
>   intuitively obvious that we should compress before encrypting if the
>   compression is to be of any use, but I don't know enough to know
>   whether the compression might somehow compromise the effectiveness of
>   the encryption.
>
> If anyone has some insight on the second of these two points, I'd
> appreciate hearing it.

About compression before encryption there is some information. For  
example: https://en.wikipedia.org/wiki/CRIME
Openssh removed compression in pre-authentication in  
http://www.openssh.com/txt/release-7.4

Regards,
Ronald.