search for: alloc_extent_st

Displaying 7 results from an estimated 7 matches for "alloc_extent_st".

2012 Jan 26
1
[PATCH] btrfs: mask out gfp flasg in releasepage
btree_releasepage is a callback and can be passed unknown gfp flags and then they may end up in kmem_cache_alloc called from alloc_extent_state, slab allocator will BUG_ON when there is HIGHMEM or DMA32 flag set. This may happen when btrfs is mounted from a loop device, which masks out __GFP_IO flag. The check in try_release_extent_state 3399 if ((mask & GFP_NOFS) == GFP_NOFS) 3400 mask = GF...
2013 Feb 25
4
WARNING: at fs/btrfs/inode.c:2165 btrfs_orphan_commit_root+0xcb/0xdf()
...blowfish_common ecb crc32c_intel aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd thermal thermal_sys Pid: 500, comm: btrfs-transacti Tainted: G O 3.7.8-amd64-preempt-20130222 #1 Call Trace: [<ffffffff81040ed4>] warn_slowpath_common+0x7e/0x96 [<ffffffff811f75c5>] ? alloc_extent_state+0x59/0xa4 [<ffffffff81040f01>] warn_slowpath_null+0x15/0x17 [<ffffffff811e972f>] btrfs_orphan_commit_root+0xcb/0xdf [<ffffffff811e3954>] commit_fs_roots.isra.24+0x99/0x153 [<ffffffff814c1ed6>] ? _raw_spin_lock+0x1b/0x1f [<ffffffff814c2059>] ? _raw_spin_unlock+0...
2012 Oct 30
8
Crashes in extent_io.c after "btrfs bad mapping eb" notice
...ff812458b8>] ? leaf_space_used+0xaf/0xd7 Oct 30 22:42:36 localhost kernel: [<ffffffff812a8044>] ? btrfs_find_all_roots+0x79/0xd4 Oct 30 22:42:36 localhost kernel: [<ffffffff812aa1d0>] ? btrfs_qgroup_account_ref+0xd2/0x4a8 Oct 30 22:42:36 localhost kernel: [<ffffffff81278482>] ? alloc_extent_state+0x58/0x9d Oct 30 22:42:36 localhost kernel: [<ffffffff810e8245>] ? kmem_cache_free+0x12/0xbd Oct 30 22:42:36 localhost kernel: [<ffffffff81253c93>] ? btrfs_delayed_refs_qgroup_accounting+0x9e/0xca Oct 30 22:42:36 localhost kernel: [<ffffffff81266723>] ? __btrfs_end_transaction+...
2010 Mar 02
3
2.6.33 high cpu usage
With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports
2011 Aug 09
17
Re: Applications using fsync cause hangs for several seconds every few minutes
On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.
2011 Aug 15
9
[patch v2 0/9] btrfs: More error handling patches
Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to
2011 Oct 04
68
[patch 00/65] Error handling patchset v3
Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them