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.
Responsible Changed From-To: freebsd-bugs->eadler take - and reminder to get secteam review of my final patch
Responsible Changed From-To: eadler->freebsd-bugs I won't be looking at this PR for a while and I need to clear some out of my queue
State Changed From-To: open->analyzed Interesting idea, I'll look at a variation of it shortly.
Responsible Changed From-To: freebsd-bugs->dougb My script.
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. Doug
Responsible Changed From-To: dougb->freebsd-bugs Back into the pool
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: 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: Author: delphij Date: Sat Nov 30 20:06:53 UTC 2019 New revision: 355247 URL: https://svnweb.freebsd.org/changeset/base/355247 Log: 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 side effect. Based on an earlier patch from peterj@. PR: 134225 Reported by: peterj Reviewed by: csprng (cem, markm) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D22612 Changes: head/libexec/save-entropy/save-entropy.sh