- By default, append to $type.$name.log.
- Get old $hostname.$pid + $type.$name symlink behavior only with
g_conf.log_per_instance
- Add new g_conf.log_file option to force a particular file.
There was a bug where we would get no reply if we could send ondisk but
the client didn't want it. This simplifies and cleans up the checks
to make more sense, removing the can_* helpers that were hiding which
checks were being done.
Signed-off-by: Sage Weil <sage@newdream.net>
If we don't release those bytes, the throttler count eventually fills up
with bytes we were going to read but didn't (due to socket errors, etc)
until we can't read anything.
Signed-off-by: Sage Weil <sage@newdream.net>
We were calling the reaper from the wait() loop. The problem is that
the OSD has two messengers, and only the first was in wait().. the second
wait() was only called after the first terminated (i.e, when the OSD was
shutting down).
Instead, launch a separate reaper thread when we bind, and close it out
on shutdown right after the accepter.
...even when the op came from another OSD. Not that that should happen
anyway, since we don't forward messages currently. (And can't, since the
OSD doesn't initiate connections to the client!)
If we take too big a bite of data to write in a single writev(2), we can
end up making performance worse, because everyone waits for the full write
to complete. Bigger writes mean better throughput but higher latency.
So, balance the two by placing some upper limit.
Hi
I got a trouble that mkcephfs will have wrong "maxosd" when you have
ceph.conf with OSD ids in random order like:
[osd2]
...
[osd0]
...
[osd1]
...
In this case, you will got "2" for the "maxosd", instead of 3.
After adding a sort, the problem seems solved.
Cheers,
CC Lien
Signed-off-by: CC Lien <cc_lien@tcloudcomputing.com>
Signed-off-by: Sage Weil <sage@newdream.net>
This was broken by bd4188a02a. @pos needs to
be advanced (it is pass by reference) or else we just overwrite the same
bytes at the journal start over and over again.
Do msgr throttle after peer policy throttle. The msgr (dispatch) throttle
is shortlived and won't deadlock (unless dispatch blocks), so it's safe to
take last. In contrast, the policy throttle carries over the lifetime of
the message, and may block until replication completes or whatever else.
crush_do_rule can return <0 in certain error cases (e.g., forcefed device
does not exist in crush map). We should take that to mean an empty []
result instead of crashing.
Signed-off-by: Sage Weil <sage@newdream.net>
