1) Comply with the way buffercache(9) is intended to be used. Now we
read in single blocks of EFS_BB_SIZE, never taking in variable
length extents with a single bread() call.
2) Handle symlinks with more than one extent. There's no reason for
this to ever happen, but it's handled now.
3) Finally, add a hint to our iteration initialiser so we can start
from the desired offset, rather than naively looping through from
the beginning each time. Since we can binary search the correct
location quickly, this improves large sequential reads by about
40% with 128MB files. Improvement should increase with file size.
When reading a file, we would erroneously iterate to the next extent
before having filled the entire uio request. This lead to unnecessary
extent iteration and excessive calls to efs_read.
Sequential read performance has doubled in the uncached case and
quadrupled when data is buffered.
- There's no need to set edata->units again, it was set already before.
- Remove the last ENVSYS_SVALID assignment that overrides previous
assignments (found by mhitch@).
state. Enable all sensors by default as valid and current valid data and
if there is one that is in invalid state, mark current data as not valid.
This matches the behaviour with the old API. Also, this fixes the problem
with ipmi(4) reporting bogus values with sensors in invalid state using
the old envstat(8).
Note that this only happened when using the old envstat(8).
can rely on all socket options being propagated from the listen socket as
the manual page says (and as everything but Linux has always done). FreeBSD 6
fixes this the same way, but this bug appears elsewhere and is...Old.
configurable via sysctl. By default it uses 10 seconds, but it can be changed
between 1 second and 5 minutes.
$ sysctl -d kern.envsys
kern.envsys.refresh_value: wait time in seconds to refresh sensors being monitored
$
portalfs. Uses the same config files etc. as the "regular"
mount_portal, and actually compiles a lot of the code directly from
under src/sbin/mount_portal.
Doesn't yet support concurrent access, but I have a pretty clear
vision on how to neatly fix that.