[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #31507 [Core Tor/Tor]: Change the client default to AvoidDiskWrites 1
#31507: Change the client default to AvoidDiskWrites 1
--------------------------------------+------------------------------------
Reporter: teor | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: security-low, 042-should | Actual Points:
Parent ID: | Points: 0.2
Reviewer: | Sponsor:
--------------------------------------+------------------------------------
Comment (by arma):
Another approach here would be to tune the "delays before writing the file
to disk", so that the default is good for the default situation, and the
parameter set by AvoidDiskWrites is now much bigger.
Looking through the code, here's what AvoidDiskWrites influences:
* In save_transport_to_state(), where we've picked an addr:port to listen
on for our pluggable transport (when we're being a bridge I guess), we
schedule our state file for a checkpoint ("or_state_mark_dirty()") but
only if AvoidDiskWrites is 0.
* In circuit_build_times_add_time(), where we just got another data point
in how long it takes to successfully build a circuit (used in tuning the
circuit build timeout feature), we call or_state_mark_dirty() every 10
circuits, but only if AvoidDiskWrites is 0.
* Similarly in circuit_build_times_update_state(), we call
or_state_mark_dirty() but only if AvoidDiskWrites is 0. This one seems
redundant since we only call circuit_build_times_update_state() from
or_state_save() with the comment near it "Call everything else that might
dirty the state even more, in order to avoid redundant writes."
* In entry_guards_changed_for_guard_selection(), when our entry guards
list has changed, we schedule a flushing of the state file to disk for
either "within 30 seconds" (default) or "within 10 minutes"
(AvoidDiskWrites).
* In entry_guards_update_state(), with the same story as
circuit_build_times_update_state() above.
* In accounting_record_bandwidth_usage(), where we checkpoint our
accountingmax style bandwidth usage. It's called every 10 minutes or every
20 megabytes (whichever comes first), plus also when we change hibernation
state, and it schedules a flushing of the state file to disk for either
"within one minute" (default) or "within two hours" (AvoidDiskWrites).
* In hibernate_begin(), where either we began hibernation or somebody sent
us a SIGINT signal to shut down, we schedule a flushing of the state file
to disk for either "now" (default) or "within 10 minutes"
(AvoidDiskWrites).
* Same story (now or 10 minutes) in hibernate_go_dormant(), which happens
when we hit our hard accountingmax and close all connections.
* In rotate_onion_key(), if we just replaced our onion key, we write the
new onion key to disk right then, and also we schedule a flushing of the
state file to disk, for either "now" or "within an hour from now", to
store the new value of state->LastRotatedOnionKey. Seems like that would
be a sad one to lose, and it happens rarely, so the best fix would to
uniformly pick "now".
* In init_keys() at startup, if we just read the state file and
LastRotatedOnionKey is 0 or in the past, we set it to now, and also
schedule a flushing of the state file for "now" or "within an hour from
now". Probably also a poor choice to wait here.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31507#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs