05 Oct, 2014
1 commit
-
Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
QUEUE_FLAG_NONROT.Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.Signed-off-by: Mike Snitzer
Signed-off-by: Jens Axboe
05 Aug, 2014
22 commits
-
this is needed for the queue/block device we created (it's done by
blk_cleanup_queue() which we do call) - but calling it for the block devices we
only opened is pointless.Change-Id: I53dfded14ed15b9581d10ca8399d5e1b3abbf9f2
-
Since bch_is_open will iterate linked list bch_cache_sets and
uncached_devices, it needs bch_register_lock.Signed-off-by: Jianjian Huo
-
time_stats::btree_gc_max_duration_mc is not bit shifted by 8
Fixes BUG #138
Change-Id: I44fc6e1d0579674016acc533f1a546b080e5371a
Signed-off-by: Surbhi Palande -
bcache_flash_dev.ktest would reliably crash with 8k and 16k bucket size
before; now it passes.Change-Id: Ib542232235e39298c3a7548fe52b645cabb823d1
-
If register_cache_set() failed, we would touch ca->set after
it had already been freed. Also, fix an assertion to catch
this.Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d
-
Change-Id: I6abde52afe917633480caaf4e2518f42a816d886
-
Signed-off-by: Kent Overstreet
-
If we goto out_nocoalesce after we free new_nodes[0], we end up freeing
new_nodes[0] again. This was generating a lockdep warning. The fix is
to set new_nodes[0] to NULL, since the out_nocoalesce path safely
ignores NULL entries in the new_nodes array.This regression was introduced in 2d7f9531.
Change-Id: I76564d7257800583214376b4bacf236cda90c89c
-
When running with multiple cache devices, if one of the devices has a completely
empty journal but we'd already found some journal entries on a previosu device
we'd go into an infinite loop.Change-Id: I1dcdc0d738192746de28f40e8b08825b0dea5e2b
Signed-off-by: Kent Overstreet -
'b' was NULL.
Change-Id: Icac0fd04afa2d23f213d96d51afd53374e6dd0c0
-
Signed-off-by: Kent Overstreet
-
Signed-off-by: Kent Overstreet
-
There's no point in blocking on these allocations, since our fallback paths will
probably go faster than blocking.Change-Id: I733ca202c25cb36bde02607a0a60552229a4241c
-
this was very wrong - mempool_alloc() only guarantees success with GFP_WAIT.
bcache uses GFP_NOWAIT in various other places where we have a fallback,
circuits must've gotten crossed when writing this code or something.Signed-off-by: Kent Overstreet
-
There were two issues here:
- writeback thread did not start until the device first became dirty
- writeback thread used uninterruptible sleep once runningWithout this patch I see kernel warnings printed and a load average of
1.52 after booting my test VM. With this patch the warnings are gone and
the load average is near 0.00 as expected.Signed-off-by: Kent Overstreet
-
Tested:
- sometimes bcache_tier test would hang on startup with a failure
to allocate the btree root -- no longer seeing thisSigned-off-by: Kent Overstreet
-
We never started the writeback thread in this case, so don't stop it.
-
while loop was executing infinitely.
This fix ends the while loop gracefully.Signed-off-by: Surbhi Palande
Signed-off-by: Kent Overstreet -
journal replay wansn't validating pointers with bch_extent_invalid() before
derefing, fixedSigned-off-by: Kent Overstreet
-
After detaching a backing device from a cache set, a bit wasn't getting
reset meaning the second detach wouldn't work correctly.Signed-off-by: Kent Overstreet
18 Apr, 2014
1 commit
-
Mostly scripted conversion of the smp_mb__* barriers.
Signed-off-by: Peter Zijlstra
Acked-by: Paul E. McKenney
Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org
Cc: Linus Torvalds
Cc: linux-arch@vger.kernel.org
Signed-off-by: Ingo Molnar
19 Mar, 2014
16 commits
-
Uninlined nested functions can cause crashes when using ftrace, as they don't
follow the normal calling convention and confuse the ftrace function graph
tracer as it examines the stack.Also, nested functions are supported as a gcc extension, but may fail on other
compilers (e.g. llvm).Signed-off-by: John Sheu
-
gc_gen was a temporary used to recalculate last_gc, but since we only need
bucket->last_gc when gc isn't running (gc_mark_valid = 1), we can just update
last_gc directly.Signed-off-by: Kent Overstreet
-
This was originally added as at optimization that for various reasons isn't
needed anymore, but it does add a lot of nasty corner cases (and it was
responsible for some recently fixed bugs). Just get rid of it now.Signed-off-by: Kent Overstreet
-
This changes the bucket allocation reserves to use _real_ reserves - separate
freelists - instead of watermarks, which if nothing else makes the current code
saner to reason about and is going to be important in the future when we add
support for multiple btrees.It also adds btree_check_reserve(), which checks (and locks) the reserves for
both bucket allocation and memory allocation for btree nodes; the old code just
kinda sorta assumed that since (e.g. for btree node splits) it had the root
locked and that meant no other threads could try to make use of the same
reserve; this technically should have been ok for memory allocation (we should
always have a reserve for memory allocation (the btree node cache is used as a
reserve and we preallocate it)), but multiple btrees will mean that locking the
root won't be sufficient anymore, and for the bucket allocation reserve it was
technically possible for the old code to deadlock.Signed-off-by: Kent Overstreet
-
With the locking rework in the last patch, this shouldn't be needed anymore -
btree_node_write_work() only takes b->write_lock which is never held for very
long.Signed-off-by: Kent Overstreet
-
Add a new lock, b->write_lock, which is required to actually modify - or write -
a btree node; this lock is only held for short durations.This means we can write out a btree node without taking b->lock, which _is_ held
for long durations - solving a deadlock when btree_flush_write() (from the
journalling code) is called with a btree node locked.Right now just occurs in bch_btree_set_root(), but with an upcoming journalling
rework is going to happen a lot more.This also turns b->lock is now more of a read/intent lock instead of a
read/write lock - but not completely, since it still blocks readers. May turn it
into a real intent lock at some point in the future.Signed-off-by: Kent Overstreet
-
This isn't a bulletproof fix; btree_node_free() -> bch_bucket_free() puts the
bucket on the unused freelist, where it can be reused right away without any
ordering requirements. It would be better to wait on at least a journal write to
go down before reusing the bucket. bch_btree_set_root() does this, and inserting
into non leaf nodes is completely synchronous so we should be ok, but future
patches are just going to get rid of the unused freelist - it was needed in the
past for various reasons but shouldn't be anymore.Signed-off-by: Kent Overstreet
-
This means the garbage collection code can better check for data and metadata
pointers to the same buckets.Signed-off-by: Kent Overstreet
-
This will potentially save us an allocation when we've got inode/dirent bkeys
that don't fit in the keylist's inline keys.Signed-off-by: Kent Overstreet
-
Break down data into clean data/dirty data/metadata.
Signed-off-by: Kent Overstreet
-
Change the invalidate tracepoint to indicate how much data we're invalidating,
and change the alloc tracepoints to indicate what offset they're for.Signed-off-by: Kent Overstreet
-
This hasn't been used or even enabled in ages.
Signed-off-by: Kent Overstreet
-
Signed-off-by: Nicholas Swenson
-
Avoid a potential null pointer deref (e.g. from check keys for cache misses)
Signed-off-by: Kent Overstreet
-
Deadlock happened because a foreground write slept, waiting for a bucket
to be allocated. Normally the gc would mark buckets available for invalidation.
But the moving_gc was stuck waiting for outstanding writes to complete.
These writes used the bcache_wq, the same queue foreground writes used.This fix gives moving_gc its own work queue, so it was still finish moving
even if foreground writes are stuck waiting for allocation. It also makes
work queue a parameter to the data_insert path, so moving_gc can use its
workqueue for writes.Signed-off-by: Nicholas Swenson
Signed-off-by: Kent Overstreet -
blk_stack_limits() doesn't like a discard granularity of 0.
Signed-off-by: Kent Overstreet
