- 09 Jun, 2011 2 commits
-
-
Josef Bacik authored
In btrfs_wait_for_commit if we came upon a transaction that had committed we just exited, but that's bad since we are holding the trans_lock. So break instead so that the lock is dropped. Thanks, Reported-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
Arne's scrub stuff exposed a problem with mapping the extent buffer in reada_for_search. He searches the commit root with multiple threads and with skip_locking set, so we can race and overwrite node->map_token since node isn't locked. So fix this so that we only map the extent buffer if we don't already have a map_token and skip_locking isn't set. Without this patch scrub would panic almost immediately, with the patch it doesn't panic anymore. Thanks, Reported-by:
Arne Jansen <sensille@gmx.net> Signed-off-by:
Josef Bacik <josef@redhat.com>
-
- 08 Jun, 2011 6 commits
-
-
Josef Bacik authored
When merging my code into the integration test the second check for duplicate entries got screwed up. This patch fixes it by dropping ret2 and just using ret for the return value, and checking if we got an error before adding the bitmap to the local list. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
I was testing with empty_cluster = 0 to try and reproduce a problem and kept hitting early enospc panics. This was because our loop logic was a little confused. So this is what I did 1) Make the loop variable the ultimate decider on wether we should loop again isntead of checking to see if we had an uncached bg, empty size or empty cluster. 2) Increment loop before checking to see what we are on to make the loop definitions make more sense. 3) If we are on the chunk alloc loop don't set empty_size/empty_cluster to 0 unless we didn't actually allocate a chunk. If we did allocate a chunk we should be able to easily setup a new cluster so clearing empty_size/empty_cluster makes us less efficient. This kept me from hitting panics while trying to reproduce the other problem. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
In cleaning up the clustering code I accidently introduced a regression by adding bitmap entries to the cluster rb tree. The problem is if we've maxed out the number of bitmaps we can have for the block group we can only add free space to the bitmaps, but since the bitmap is on the cluster we can't find it and we try to create another one. This would result in a panic because the total bitmaps was bigger than the max bitmaps that were allowed. This patch fixes this by checking to see if we have a cluster, and then looking at the cluster rb tree to see if it has a bitmap entry and if it does and that space belongs to that bitmap, go ahead and add it to that bitmap. I could hit this panic every time with an fs_mark test within a couple of minutes. With this patch I no longer hit the panic and fs_mark goes to completion. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
I noticed when running an enospc test that we would get stuck committing the transaction in check_data_space even though we truly didn't have enough space. So check to see if bytes_pinned is bigger than num_bytes, if it's not don't commit the transaction. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
When profiling the find cluster code it's hard to tell where we are spending our time because the bitmap and non-bitmap functions get inlined by the compiler, so make that not happen. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
Josef Bacik authored
If we are looking for a cluster in a particularly sparse or fragmented block group, we will do a lot of looping through the free space tree looking for various things, and if we need to look at bitmaps we will endup doing the whole dance twice. So instead add the bitmap entries to a temporary list so if we have to do the bitmap search we can just look through the list of entries we've found quickly instead of having to loop through the entire tree again. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com>
-
- 04 Jun, 2011 11 commits
-
-
David Sterba authored
With Linus' tree, today's linux-next build (powercp ppc64_defconfig) produced this warning: fs/btrfs/delayed-inode.c: In function 'btrfs_delayed_update_inode': fs/btrfs/delayed-inode.c:1598:6: warning: 'ret' may be used uninitialized in this function Introduced by commit 16cdcec7 ("btrfs: implement delayed inode items operation"). This fixes a bug in btrfs_update_inode(): if the returned value from btrfs_delayed_update_inode is a nonzero garbage, inode stat data are not updated and several call paths may hit a BUG_ON or fail with strange code. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
David Sterba <dsterba@suse.cz>
-
David Sterba authored
wrap checking of filesystem 'closing' flag and fix a few missing memory barriers. Signed-off-by:
David Sterba <dsterba@suse.cz>
-
Chris Mason authored
This makes the inode map cache default to off until we fix the overflow problem when the free space crcs don't fit inside a single page. Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Arne Jansen authored
With the removal of the implicit plugging scrub ends up doing more and smaller I/O than necessary. This patch adds explicit plugging per chunk. Signed-off-by:
Arne Jansen <sensille@gmx.net> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
David Sterba authored
commit 4cb5300b ("Btrfs: add mount -o auto_defrag") accesses inode number directly while it should use the helper with the new inode number allocator. Signed-off-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Josef Bacik authored
With xfstest 254 I can panic the box every time with the inode number caching stuff on. This is because we clean the inodes out when we delete the subvolume, but then we write out the inode cache which adds an inode to the subvolume inode tree, and then when it gets evicted again the root gets added back on the dead roots list and is deleted again, so we have a double free. To stop this from happening just return 0 if refs is 0 (and we're not the tree root since tree root always has refs of 0). With this fix 254 no longer panics. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com> Tested-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Arne Jansen authored
In degraded mode the struct btrfs_device of missing devs don't have device->name set. A kstrdup of NULL correctly returns NULL. Don't BUG in this case. Signed-off-by:
Arne Jansen <sensille@gmx.net> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
liubo authored
This adds extra checks to make sure the inode map we are caching really belongs to a FS root instead of a special relocation tree. It prevents crashes during balancing operations. Signed-off-by:
Liu Bo <liubo2009@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
The free space cache uses only one page for crcs right now, which means we can't have a cache file bigger than the crcs we can fit in the first page. This adds a check to enforce that restriction. Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
The nitems counter needs to start at zero Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Arne Jansen authored
The current scrub implementation reuses bios and pages as often as possible, allocating them only on start and releasing them when finished. This leads to more problems with the block layer than it's worth. The elevator gets confused when there are more pages added to the bio than bi_size suggests. This patch completely rips out the reuse of bios and pages and allocates them freshly for each submit. Signed-off-by:
Arne Jansen <sensille@gmx.net> Signed-off-by:
Chris Maosn <chris.mason@oracle.com>
-
- 28 May, 2011 1 commit
-
-
Chris Mason authored
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work into for-linus Conflicts: fs/btrfs/disk-io.c fs/btrfs/extent-tree.c fs/btrfs/free-space-cache.c fs/btrfs/inode.c fs/btrfs/transaction.c Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
- 27 May, 2011 1 commit
-
-
Chris Mason authored
write_dev_supers was changed to use RCU to protect the list of devices, but it was then sleeping while it actually wrote the supers. This fixes it to just use the mutex, since we really don't any concurrency in write_dev_supers anyway. Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
- 26 May, 2011 4 commits
-
-
Li Zefan authored
For a filesystem that has lots of files in it, the first time we mount it with free ino caching support, it can take quite a long time to setup the caching before we can create new files. Here we fill the cache with [highest_ino, BTRFS_LAST_FREE_OBJECTID] before we start the caching thread to search through the extent tree. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Arne Jansen authored
scrub_page collects several pages into one bio as long as they are physically contiguous. As we only save one logical address for the whole bio, don't collect pages that are physically contiguous but logically discontiguous. Signed-off-by:
Arne Jansen <sensille@gmx.net> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
The btrfs releasepage function depends on ENOMEM coming back when it is called atomic. Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
This will detect small random writes into files and queue the up for an auto defrag process. It isn't well suited to database workloads yet, but works for smaller files such as rpm, sqlite or bdb databases. Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
- 23 May, 2011 15 commits
-
-
Chris Mason authored
Conflicts: fs/btrfs/tree-log.c fs/btrfs/volumes.c Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
fs_devices->devices is only updated on remove and add device paths, so we can use rcu to protect it in the reader side Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
Drop device_list_mutex for the reader side on clone_fs_devices and btrfs_rm_device pathes since the fs_info->volume_mutex can ensure the device list is not updated btrfs_close_extra_devices is the initialized path, we can not add or remove device at this time, so we can simply drop the mutex safely, like other initialized function does(add_missing_dev, __find_device, __btrfs_open_devices ...). Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
On remove device path, it updates device->dev_alloc_list but does not hold chunk lock Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
On btrfs_congested_fn and __unplug_io_fn paths, we should hold device_list_mutex to avoid remove/add device path to update fs_devices->devices On __btrfs_close_devices and btrfs_prepare_sprout paths, the devices in fs_devices->devices or fs_devices->devices is updated, so we should hold the mutex to avoid the reader side to reach them Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
'bh' is forgot to release if no error is detected Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
merge_state can free the current state if it can be merged with the next node, but in set_extent_bit(), after merge_state, we still use the current extent to get the next node and cache it into cached_state Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Xiao Guangrong authored
It doesn't allocate extent_state and check the result properly: - in set_extent_bit, it doesn't allocate extent_state if the path is not allowed wait - in clear_extent_bit, it doesn't check the result after atomic-ly allocate, we trigger BUG_ON() if it's fail - if allocate fail, we trigger BUG_ON instead of returning -ENOMEM since the return value of clear_extent_bit() is ignored by many callers Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Julia Lawall authored
Btrfs_alloc_path should be matched with btrfs_free_path in error-handling code. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression struct btrfs_path * x; expression ra,rb; position p1,p2; @@ x = btrfs_alloc_path@p1(...) ... when != btrfs_free_path(x,...) when != if (...) { ... btrfs_free_path(x,...) ...} when != x = ra if(...) { ... when != x = rb when forall when != btrfs_free_path(x,...) \(return <+...x...+>; \| return@p2...; \) } @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("alloc",p1) cocci.print_secs("return",p2) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Tsutomu Itoh authored
If return value of btrfs_inc_extent_ref() is not 0, BUG() is called. Signed-off-by:
Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Tsutomu Itoh authored
When read_one_inode() fails, error code is returned to caller instead of BUG_ON(). Signed-off-by:
Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Tsutomu Itoh authored
Currently, btrfs_truncate_item and btrfs_extend_item returns only 0. So, the check by BUG_ON in the caller is unnecessary. Signed-off-by:
Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Tsutomu Itoh authored
The error code is returned instead of calling BUG_ON when btrfs_del_item returns the error. Signed-off-by:
Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Tsutomu Itoh authored
The error code is returned instead of calling BUG_ON when btrfs_previous_item returns the error. Signed-off-by:
Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-
Sergei Trofimovich authored
Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by:
Chris Mason <chris.mason@oracle.com>
-