client: Respect O_SYNC, O_DSYNC, and O_RSYNC

If the file is opened with O_SYNC, O_DSYNC, or O_RSYNC, we need to
flush cached data (and metadata for O_SYNC) on a write.
For O_RSYNC, we need to flush dirty data on a read.
This patch adds a file_flush() call to the objectCacher
to allow a specific range to be flushed from the cache, and
in the O_SYNC,O_DSYNC case for write and O_RSYNC case for read,
calls that function waiting for the flush to complete.  The patch
also adds a flags field directly to the file handle struct, and
replaces the append boolean with the use of the flags field directly.

Signed-off-by: Sam Lang <sam.lang@inktank.com>
config: don't make noise about 'internal_safe_to_start_threads'

This is set on start, and subsequently gets into the changed set.
Once any other config value is injected, it is the first thing reported
by the logs, but is confusing and useless to the user.  Hide it.

Signed-off-by: Sage Weil <sage@inktank.com>
config: clean up output

Report a simple list of key='value', without extra verbosity.

Signed-off-by: Sage Weil <sage@inktank.com>
config: report on log level changes

Signed-off-by: Sage Weil <sage@inktank.com>
Merge branch 'wip-config'

Reviewed-by: Yehuda Sadeh <yehuda@inktank.com>
testing: add workunit to run hadoop internal tests.

This workunit runs the internal tests for our local branch of hadoop-common.
Requires ant be installed on the host running the test.

Signed-off-by: Joe Buck <jbbuck@gmail.com>
objectcacher: Remove commit_set, use flush_set

commit_set() and flush_set() are identical in functionality,
so use flush_set everywhere and remove commit_set from
the code.

Also fixes a bug in flush_set where the finisher context was
getting freed twice if no objects needed to be flushed.

Signed-off-by: Sam Lang <sam.lang@inktank.com>
qa/workunit: Add iozone test script for sync

The iozone-sync.sh script runs iozone testing
various sync flags, O_SYNC, O_DSYNC, O_RSYNC.

Signed-off-by: Sam Lang <sam.lang@inktank.com>
osd: make OSD a config observer

Signed-off-by: Sage Weil <sage@inktank.com>
osd: make osd_max_backfills dynamically adjustable

Signed-off-by: Sage Weil <sage@inktank.com>
os/FileStore: allow filestore_queue_max_{ops,bytes} to be adjusted at runtime

The 'committing' ones too.

Signed-off-by: Sage Weil <sage@inktank.com>
filestore: disable extra committing queue allowance

The motivation here is if there is a problem draining the op queue
during a sync.  For XFS and ext4, this isn't generally a problem: you
can continue to make writes while a syncfs(2) is in progress.  There
are currently some possible implementation issues with btrfs, but we
have not demonstrated them recently.

Meanwhile, this can cause queue length spikes that screw up latency.
During a commit, we allow too much into the queue (say, recovery
operations).  After the sync finishes, we have to drain it out before
we can queue new work (say, a higher priority client request).  Having
a deep queue below the point where priorities order work limits the
value of the priority queue.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: target transaction size 300 -> 30

Small transactions make pg removal nicer to the op queue.  It also slows
down PG deletion a bit, which may exacerbate the PG resurrection case
until #3884 is addressed.

At least on user reported this fixed an osd that kept failing due to
an internal heartbeat failure.

Signed-off-by: Sage Weil <sage@inktank.com>
filestore: filestore_queue_max_ops 500 -> 50

Having a deep queue limits the effectiveness of the priority queues
above by adding additional latency.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: debug msg prio, cost, latency

Signed-off-by: Sage Weil <sage@inktank.com>
osd: use Message::get_cost() function for queueing

The data payload is a decent proxy for cost in most cases, but not all.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: set PULL subop cost to size of requested data

Signed-off-by: Sage Weil <sage@inktank.com>
osd: add OpRequest flag point when commit is sent

With writeahead journaling in particular, we can get requests that
stay in the queue for a long time even after the commit is sent to the
client while we are waiting for the transaction to apply to the fs.
Instead of showing up as 'waiting for subops', make it clear that the
client has gotten its reply and it is local state that is slow.

Signed-off-by: Sage Weil <sage@inktank.com>
note puller's max chunk in pull requests

this lets us calculate a cost value
common/PrioritizedQueue: buckets -> tokens

Signed-off-by: Sage Weil <sage@inktank.com>