- Jul 12, 2013
-
-
Kent Overstreet authored
The alloc kthread should've been using try_to_freeze() - and also there was the potential for the alloc kthread to get woken up after it had shut down, which would have been bad. Signed-off-by:
Kent Overstreet <kmo@daterainc.com>
-
Kent Overstreet authored
Part of the job of garbage collection is to add up however many sectors of live data it finds in each bucket, but that doesn't work very well if it doesn't reset GC_SECTORS_USED() when it starts. Whoops. This wouldn't have broken anything horribly, but allocation tries to preferentially reclaim buckets that are mostly empty and that's not gonna work with an incorrect GC_SECTORS_USED() value. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
Kent Overstreet authored
The journal replay code starts by finding something that looks like a valid journal entry, then it does a binary search over the unchecked region of the journal for the journal entries with the highest sequence numbers. Trouble is, the logic was wrong - journal_read_bucket() returns true if it found journal entries we need, but if the range of journal entries we're looking for loops around the end of the journal - in that case journal_read_bucket() could return true when it hadn't found the highest sequence number we'd seen yet, and in that case the binary search did the wrong thing. Whoops. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
Kent Overstreet authored
Stopping a cache set is supposed to make it stop attached backing devices, but somewhere along the way that code got lost. Fixing this mainly has the effect of fixing our reboot notifier. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
Kent Overstreet authored
If we stopped a bcache device when we were already detaching (or something like that), bcache_device_unlink() would try to remove a symlink from sysfs that was already gone because the bcache dev kobject had already been removed from sysfs. So keep track of whether we've removed stuff from sysfs. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
Kent Overstreet authored
Whoops - bcache's flush/FUA was mostly correct, but flushes get filtered out unless we say we support them... Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
Dan Carpenter authored
There is a missing NULL check after the kzalloc(). Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com>
-
Kent Overstreet authored
In the far-too-complicated closure code - closures can have destructors, for probably dubious reasons; they get run after the closure is no longer waiting on anything but before dropping the parent ref, intended just for freeing whatever memory the closure is embedded in. Trouble is, when remaining goes to 0 and we've got nothing more to run - we also have to unlock the closure, setting remaining to -1. If there's a destructor, that unlock isn't doing anything - nobody could be trying to lock it if we're about to free it - but if the unlock _is needed... that check for a destructor was racy. Argh. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
-
- Jul 01, 2013
-
-
Kent Overstreet authored
Some of bcache's utility code has made it into the rest of the kernel, so drop the bcache versions. Bcache used to have a workaround for allocating from a bio set under generic_make_request() (if you allocated more than once, the bios you already allocated would get stuck on current->bio_list when you submitted, and you'd risk deadlock) - bcache would mask out __GFP_WAIT when allocating bios under generic_make_request() so that allocation could fail and it could retry from workqueue. But bio_alloc_bioset() has a workaround now, so we can drop this hack and the associated error handling. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
This code has rotted and it hasn't been used in ages anyways. Signed-off-by:
Kent Overstreet <kmo@daterainc.com>
-
Kent Overstreet authored
Signed-off-by:
Kent Overstreet <kmo@daterainc.com>
-
Kent Overstreet authored
Journal writes need to be marked FUA, not just REQ_FLUSH. And btree node writes have... weird ordering requirements. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Jun 27, 2013
-
-
Gabriel de Perthuis authored
Signed-off-by:
Gabriel de Perthuis <g2p.code@gmail.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Gabriel de Perthuis authored
Signed-off-by:
Gabriel de Perthuis <g2p.code@gmail.com>
-
Kent Overstreet authored
Now that we're tracking dirty data per stripe, we can add two optimizations for raid5/6: * If a stripe is already dirty, force writes to that stripe to writeback mode - to help build up full stripes of dirty data * When flushing dirty data, preferentially write out full stripes first if there are any. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
To make background writeback aware of raid5/6 stripes, we first need to track the amount of dirty data within each stripe - we do this by breaking up the existing sectors_dirty into per stripe atomic_ts Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Previously, dirty_data wouldn't get initialized until the first garbage collection... which was a bit of a problem for background writeback (as the PD controller keys off of it) and also confusing for users. This is also prep work for making background writeback aware of raid5/6 stripes. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
The old lazy sorting code was kind of hacky - rewrite in a way that mathematically makes more sense; the idea is that the size of the sets of keys in a btree node should increase by a more or less fixed ratio from smallest to biggest. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Old gcc doesnt like the struct hack, and it is kind of ugly. So finish off the work to convert pr_debug() statements to tracepoints, and delete pkey()/pbtree(). Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
The tracepoints were reworked to be more sensible, and fixed a null pointer deref in one of the tracepoints. Converted some of the pr_debug()s to tracepoints - this is partly a performance optimization; it used to be that with DEBUG or CONFIG_DYNAMIC_DEBUG pr_debug() was an empty macro; but at some point it was changed to an empty inline function. Some of the pr_debug() statements had rather expensive function calls as part of the arguments, so this code was getting run unnecessarily even on non debug kernels - in some fast paths, too. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
The most significant change is that btree reads are now done synchronously, instead of asynchronously and doing the post read stuff from a workqueue. This was originally done because we can't block on IO under generic_make_request(). But - we already have a mechanism to punt cache lookups to workqueue if needed, so if we just use that we don't have to deal with the complexity of doing things asynchronously. The main benefit is this makes the locking situation saner; we can hold our write lock on the btree node until we're finished reading it, and we don't need that btree_node_read_done() flag anymore. Also, for writes, btree_write() was broken out into btree_node_write() and btree_leaf_dirty() - the old code with the boolean argument was dumb and confusing. The prio_blocked mechanism was improved a bit too, now the only counter is in struct btree_write, we don't mess with transfering a count from struct btree anymore. This required changing garbage collection to block prios at the start and unblock when it finishes, which is cleaner than what it was doing anyways (the old code had mostly the same effect, but was doing it in a convoluted way) And the btree iter btree_node_read_done() uses was converted to a real mempool. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Using a workqueue when we just want a single thread is a bit silly. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Gabriel de Perthuis authored
Signed-off-by:
Gabriel de Perthuis <g2p.code+bcache@gmail.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
An old version of gcc was complaining about using a const int as the size of a stack allocated array. Which should be fine - but using ARRAY_SIZE() is better, anyways. Also, refactor the code to use scnprintf(). Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kumar Amit Mehta authored
bio_alloc_bioset returns NULL on failure. This fix adds a missing check for potential NULL pointer dereferencing. Signed-off-by:
Kumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Jun 18, 2013
-
-
Phil Viana authored
The word 'arithmetic' was typed as 'arithmatic' Signed-off-by:
Phil Viana <phillip.l.viana@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- May 15, 2013
-
-
Kent Overstreet authored
This code appears to have rotted... fix various bugs and do some refactoring. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Paul Bolle authored
The Kconfig entry for BCACHE selects CLOSURES. But there's no Kconfig symbol CLOSURES. That symbol was used in development versions of bcache, but was removed when the closures code was no longer provided as a kernel library. It can safely be dropped. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl>
-
Emil Goode authored
The function pointer release in struct block_device_operations should point to functions declared as void. Sparse warnings: drivers/md/bcache/super.c:656:27: warning: incorrect type in initializer (different base types) drivers/md/bcache/super.c:656:27: expected void ( *release )( ... ) drivers/md/bcache/super.c:656:27: got int ( static [toplevel] *<noident> )( ... ) drivers/md/bcache/super.c:656:2: warning: initialization from incompatible pointer type [enabled by default] drivers/md/bcache/super.c:656:2: warning: (near initialization for ‘bcache_ops.release’) [enabled by default] Signed-off-by:
Emil Goode <emilgoode@gmail.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- May 01, 2013
-
-
Kent Overstreet authored
Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
The main fix is that bch_allocator_thread() wasn't waiting on garbage collection to finish (if invalidate_buckets had set ca->invalidate_needs_gc); we need that to make sure the allocator doesn't spin and potentially block gc from finishing. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Apr 24, 2013
-
-
Kent Overstreet authored
Sanity check to make sure we don't end up doing IO the device doesn't support. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Apr 22, 2013
-
-
Kent Overstreet authored
Stacked md devices reuse the bvm for the subordinate device, causing problems... Reported-by:
Michael Balser <michael.balser@profitbricks.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Apr 21, 2013
-
-
Kent Overstreet authored
bch_bio_max_sectors() was checking against BIO_MAX_PAGES as if the limit was for the total bytes in the bio, not the number of segments. Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Add a new superblock version, and consolidate related defines. Signed-off-by:
Gabriel de Perthuis <g2p.code+bcache@gmail.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
- Apr 08, 2013
-
-
Kent Overstreet authored
Reported-by:
<sasha.levin@oracle.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-
Kent Overstreet authored
Reported-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Kent Overstreet <koverstreet@google.com>
-