By default, save-entropy is run by cron every 11 minutes to
provide some initial entropy following a system reboot. It
uses the standard log-rotating approach to maintain 8 entropy
files, with the most recent always being saved-entropy.1
suffix and the oldest file being deleted. As a result, each
run of save-entropy causes 7 file renames, 1 file create &
write and 1 file delete.
There does not appear to be any special reason for keeping the
most recent entropy dump in a fixed name - the order of
reloading the entropy files should not affect the total amount
of entropy loaded into the kernel. In order to reduce the
number of writes to the SSD in my laptop, I therefore
re-engineered save-entropy to just overwrite the oldest file
in-place. This means that only the 2KB of entropy and 1 inode
are touched. In particular, by not deleting/recreating the
file, $entropy_dir is not touched.
How-To-Repeat: Code inspection. Monitoring disk write transfers via devstat.
take - and reminder to get secteam review of my final patch
I won't be looking at this PR for a while and I need to clear some out
of my queue
Interesting idea, I'll look at a variation of it shortly.
FWIW, part of the reason for rotation is to use different/newer files
first on a subsequent boot where uptime was not long enough to replace
all the files. However, I'd like to see that issue addressed by
pseudo-randomizing the order in which the files in /var/db/entropy are
used by rc.d/random, so once that is done this type of change should be
both safe and desirable.
Other considerations, make sure that there are at least
$entropy_save_num files with >0 size before replacing one of them. (So
that if 1 or more files are accidentally deleted, you are still adding
to the total number of files.) The same pre-processing loop could test
that, and test what the oldest file is.
Back into the pool
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Proposed patch https://reviews.freebsd.org/D22612
A commit references this bug:
Date: Sat Nov 30 20:06:53 UTC 2019
New revision: 355247
Reduce disk write load in /usr/libexec/save-entropy.
Before this commit, the save-entropy script rotates entropy files
like logs. This involves creating a new file that holds the entropy
and renaming of all existing entropy files. However, the entropy
data do not really need to be kept in a particular order, and
replacing the oldest file is sufficient.
This commit replaces the rotation with a scan in the
[1..entropy_save_num] space that finds the first empty slot, or
the slot of the oldest file, and writes entropy into that slot.
This also fixes an issue that prevents save-entropy from saving
any entropy when there is one non-regular file in any slot as a
Based on an earlier patch from peterj@.
Reported by: peterj
Reviewed by: csprng (cem, markm)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22612