- 01 Sep, 2013 39 commits
-
-
Filipe David Borba Manana authored
Signed-off-by:
Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
Chris Mason <chris.mason@fusionio.com>
-
Dave Jones authored
If we bail out when the stripe alloc fails, we need to undo the earlier allocation of raid_map. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Filipe David Borba Manana authored
Signed-off-by:
Jan Schmidt <list.btrfs@jan-o-sch.net> Signed-off-by:
-
Filipe David Borba Manana authored
After reading all device items from the chunk tree, don't exit the loop and then navigate down the tree again to find the chunk items. Instead just read all device items and chunk items with a single tree search. This is possible because all device items are found before any chunk item in the chunks tree. Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Signed-off-by:
-
Josef Bacik authored
There is no reason for this sort of jackassery. Thanks, Signed-off-by:
-
Josef Bacik authored
Previously we only added blocks to the list to have their backrefs checked if the level of the block is right above the one we are searching for. This is because we want to make sure we don't add the entire path up to the root to the lists to make sure we process things one at a time. This assumes that if any blocks in the path to the root are going to be not checked (shared in other words) then they will be in the level right above the current block on up. This isn't quite right though since we can have blocks higher up the list that are shared because they are attached to a reloc root. But we won't add this block to be checked and then later on we will BUG_ON(!upper->checked). So instead keep track of wether or not we've queued a block to be checked in this current search, and if we haven't go ahead and queue it to be checked. This patch fixed the panic I was seeing where we BUG_ON(!upper->checked). Thanks, Signed-off-by:
-
Josef Bacik authored
If our item isn't big enough to have an actual inline item when we have skinny metadata enabled just return 1 in find_inline_backref so we can move on to the next item. This probably wasn't causing a problem since we check the values of ptr and end properly, but just in case this will keep us from doing extra work. Thanks, Signed-off-by:
-
Josef Bacik authored
First of all we no longer set EXTENT_DIRTY when we dirty an extent so this patch removes the clearing of EXTENT_DIRTY since it confuses me. This patch also adds clearing EXTENT_DEFRAG and also doing EXTENT_DO_ACCOUNTING when we have errors. This is because if we are clearing delalloc without adding an ordered extent then we need to make sure the enospc handling stuff is accounted for. Also if this range was DEFRAG we need to make sure that bit is cleared so we dont leak it. Thanks, Signed-off-by:
-
Josef Bacik authored
This patch removes the io_tree argument for extent_clear_unlock_delalloc since we always use &BTRFS_I(inode)->io_tree, and it separates out the extent tree operations from the page operations. This way we just pass in the extent bits we want to clear and then pass in the operations we want done to the pages. This is because I'm going to fix what extent bits we clear in some cases and rather than add a bunch of new flags we'll just use the actual extent bits we want to clear. Thanks, Signed-off-by:
-
Anand Jain authored
Signed-off-by:
Anand Jain <anand.jain@oracle.com> Signed-off-by:
-
Miao Xie authored
When we read several pages at once, we needn't get the extent map object every time we deal with a page, and we can cache the extent map object. So, we can reduce the search time of the extent map, and besides that, we also can reduce the lock contention of the extent map tree. Signed-off-by:
-
Miao Xie authored
In the past, we cached the checksum value in the extent state object, so we had to split the extent state object by the block size, or we had no space to keep this checksum value. But it increased the lock contention of the extent state tree. Now we removed this limit by caching the checksum into the bio object, so it is unnecessary to do the extent state operations by the block size, we can do it in batches, in this way, we can reduce the lock contention of the extent state tree. Signed-off-by:
-
Miao Xie authored
Before applying this patch, we set the uptodate flag and unlock the extent by the page size, it is unnecessary, we can do it in batches, it can reduce the lock contention of the extent state tree. Signed-off-by:
-
Miao Xie authored
Before applying this patch, we cached the csum value into the extent state tree when reading some data from the disk, this operation increased the lock contention of the state tree. Now, we just store the csum value into the bio structure or other unshared structure, so we can reduce the lock contention. Signed-off-by:
-
Miao Xie authored
This patch add some branch prediction hints into the end IO function of the read page, it reduced the percentage of the branch misses from 5.5% to 4.9%. Signed-off-by:
-
Miao Xie authored
Signed-off-by:
-
Wang Shilong authored
Some options are missing in btrfs_show_options(), this patch adds them. Signed-off-by:
Wang Shilong <wangsl.fnst@cn.fujitsu.com> Reviewed-by:
-
Wang Shilong authored
Although for most time, int is enough for subvolid, we should ensure safety in theory. Signed-off-by:
-
Wang Shilong authored
I just notice the following commands succeed: mount <dev> <mnt> -o thread_pool=-1 This is ridiculous, only positive thread_pool makes sense,this patch adds sanity checks for them, and also catches the error of ENOMEM if allocating memory fails. Signed-off-by:
-
Miao Xie authored
Signed-off-by:
-
Dan Carpenter authored
The alloc_rbio() frees "raid_map" and "bbio" on error, so there is a potential double free bug in raid56_parity_write(). The raid56_parity_write() and raid56_parity_recover() functions should still free "raid_map" and "bbio" on error if other errors occur though, so I have added some more calls to kfree(). Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Josef Bacik authored
We can end up with inodes on the auto defrag list that exist on roots that are going to be deleted. This is extra work we don't need to do, so just bail if our root has 0 root refs. Thanks, Signed-off-by:
-
Josef Bacik authored
I was hitting the BUG_ON() at the end of merge_reloc_roots() because we were aborting the transaction at some point previously and then getting an error when we tried to drop the reloc root. I fixed btrfs_drop_snapshot to re-add us to the dead roots list if we failed, but this isn't the right thing to do for reloc roots since it uses root->root_list for it's own stuff in order to know what needs to be cleaned up. So fix btrfs_drop_snapshot to only do the re-add if we aren't dropping for reloc, and handle errors from merge_reloc_root() by dropping the reloc root we are processing since it won't be on the list of roots to cleanup. With this patch my reproducer no longer panics. Thanks, Signed-off-by:
-
Josef Bacik authored
I was getting warnings when running find ./ -type f -exec btrfs fi defrag -f {} \; from record_one_backref because ret was set. Turns out it was because it was set to 1 because the search slot didn't come out exact and we never reset it. So reset it to 0 right after the search so we don't leak this and get uneccessary warnings. Thanks, Signed-off-by: -
Anand Jain authored
btrfs_ioctl_get_fslabel() and btrfs_ioctl_set_fslabel() used root->fs_info->volume_mutex mutex which caused operations like balance to block set/get label operation until its completion and generally balance operation takes a long time to complete, so it will be annoying to the user when cli appears hung also this patch will add a bit of optimization within the btrfs_ioctl_get_falabel() function. v1->v2: use fs_info->super_lock instead of uuid_mutex Signed-off-by:
-
Stefan Behrens authored
This is confusing, sometimes the key type is printed in hex (without a leading "0x" which makes things even more complicated), sometimes in decimal... Change it to be in decimal everywhere. Signed-off-by:
Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by:
-
Liu Bo authored
This shows exactly how btrfs processes the delayed refs onto disks, which is very helpful on understanding delayed ref mechanism and debugging related bugs. Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
-
chandan authored
btrfs_space_info->block_groups. The current code uses integer literals to index btrfs_space_info->block_groups[] array. Instead use corresponding enums from 'enum btrfs_raid_types'. Signed-off-by:
chandan <chandan@linux.vnet.ibm.com> Reviewed-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
-
Qu Wenruo authored
Some codes still use the cpu_to_lexx instead of the BTRFS_SETGET_STACK_FUNCS declared in ctree.h. Also added some BTRFS_SETGET_STACK_FUNCS for btrfs_header btrfs_timespec and other structures. Signed-off-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Reviewed-by:
Miao Xie <miaoxie@cn.fujitsu.com> Reviewed-by:
-
Wang Shilong authored
We call ulist_free(qgroup_ulist) in btrfs_free_qgroup_config(), and btrfs_free_qgroup_config() may be called in two cases: (1)umount filesystem (2)disabling quota However, if we firstly disable quota and then umount filesystem, a double free happens. Fix it. Signed-off-by:
-
Filipe David Borba Manana authored
The function relocation.c:add_data_references() was not checking if all calls to __add_tree_block() and find_data_references() were succeeding or not. Signed-off-by:
-
David Sterba authored
The log message level 'critical' is verbose enough, 'emergency' beeps on all terminals. Signed-off-by:
-
Liu Bo authored
So to cache free space, we iterate every extent item to gather free space info. When we have say 10,000 non-inline extent refs(such as BTRFS_EXTENT_DATA_REF), it takes quite a long time, and since inline extent refs and non-inline ones have same objectid in their keys, we can just re-search the tree with the next address to skip non-inline references. (This is found by dedup feature because dedup extents can end up with many non-inline extent refs.) Signed-off-by:
-
Jeff Mahoney authored
I recently did some ENOSPC testing that involved filling the disk while create and removing snapshots in a loop. During the test cycle, I ran into an ENOSPC when trying to remove a snapshot, leaving the fs stuck in ENOSPC even after a umount/mount cycle. This patch allow subvolume removal to fall back onto the global block reservation in order to succeed when it would have failed otherwise. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Filipe David Borba Manana authored
If we're looking for a metadata item in the tree and the search fails with return value of 1, and the slot doesn't point to the first item in the leaf, check if the previous item in the leaf corresponds to an extent item for the same object id - if it does, then don't do another tree search to get it. This optimization is already done by btrfs-progs. V2: updated commit message. Signed-off-by:
-
Carey Underwood authored
Device scanning waits on the uuid_mutex, which can result in a very long wait if dev delete is shrinking the device. Signed-off-by:
Carey Underwood <cwillu@cwillu.com> Reviewed-by:
-
Josef Bacik authored
We've been seeing spurious complaints out of lockdep because the lock class name changes. This is happening because when we drop a snapshot we will lock a block before we've read it in, which sets the lockdep class to whatever the default is. Then once we read the thing in we reset the lockdep class to what it is supposed to be, which blows lockdeps' mind. This patch should fix the problem, it appears to be the only place where we do this sort of thing. Thanks, Signed-off-by:
-
Stefan Agner authored
With this fix the lzo code behaves like the zlib code by returning an error code when compression does not help reduce the size of the file. This is currently not a bug since the compressed size is checked again in the calling method compress_file_range. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Josef Bacik authored
Previously we held the tree mod lock when adding stuff because we use it to check and see if we truly do want to track tree modifications. This is admirable, but GFP_ATOMIC in a critical area that is going to get hit pretty hard and often is not nice. So instead do our basic checks to see if we don't need to track modifications, and if those pass then do our allocation, and then when we go to insert the new modification check if we still care, and if we don't just free up our mod and return. Otherwise we're good to go and we can carry on. Thanks, Signed-off-by:
-
- 26 Aug, 2013 1 commit
-
-
Linus Torvalds authored
-
