On Mon, Oct 10, 2011 at 7:09 PM, Fajar A. Nugraha <l...@fajar.net> wrote:
> On Mon, Oct 10, 2011 at 5:20 PM, David Sterba <d...@jikos.cz> wrote:
>> On Mon, Oct 10, 2011 at 02:30:30PM +0700, Fajar A. Nugraha wrote:
>>> This happens both with natty's 2.6.38-11-generic and kernel 3.0.4
>>> (backported from oneiric). Does anyone know if this is a know problem,
>>> or how to get further information to fix this?
>>
>> I'm afraid with the kernels that old, nobody will try to fix it unless
>> you reproduce it on the most recent kernels.
>
> 3.0.4 is considered old already? Wow, 3.1 is not even out yet
>
> I'll retry with 3.1-rc9 then.

Well, apparently 3.0.4 IS old in btrfs world :) With 3.1-rc9, it looks
stuck for a while (same high cpu load), but after a while it completes
succesfully

>> I'd be good to know where excatly the ls is stuck by 'cat
>> /proc/<lspid>/stack', and if it's in D state, possibly gethering stacks
>> of all such processes.
>
> cpu usage of the ls process is 96-99%
>
> The good news is that it seems to be doing something (the stack
> changes somewhat). The bad news is that it seems stuck in a loop. This
> is on kernel 3.0.4
>
> $ for n in `seq 1 10`;do echo "=============================";sudo cat
> /proc/9354/stack;done
> =============================
> [<c1041ebb>] __cond_resched+0x1b/0x30
> [<c113b3f9>] iget5_locked+0x79/0x1a0
> [<f8572ccc>] btrfs_iget+0x3c/0x4a0 [btrfs]
> [<f8573278>] btrfs_orphan_cleanup+0x148/0x320 [btrfs]
> [<f8573757>] btrfs_lookup_dentry+0x307/0x4a0 [btrfs]
> [<f8573900>] btrfs_lookup+0x10/0x30 [btrfs]
> [<c112cf27>] d_alloc_and_lookup+0x37/0x70
> [<c112eb89>] do_lookup+0x279/0x2f0
> [<c112f977>] path_lookupat+0x107/0x5e0
> [<c112fe7c>] do_path_lookup+0x2c/0xb0
> [<c11302b3>] user_path_at+0x43/0x80
> [<c1128165>] vfs_fstatat+0x55/0xa0
> [<c11281d0>] vfs_lstat+0x20/0x30
> [<c11285a6>] sys_lstat64+0x16/0x30
> [<c150b3e4>] syscall_call+0x7/0xb
> [<ffffffff>] 0xffffffff


The stack looks a little different. The 3.0.4 sometimes has this while
3.1-rc9 doesn't (at least I wasn't able to capture it)

[<f8545222>] generic_bin_search.clone.39+0x162/0x210 [btrfs]

...and 3.0.4 has these

[<f8573900>] btrfs_lookup+0x10/0x30 [btrfs]
[<c112cf27>] d_alloc_and_lookup+0x37/0x70
[<c112eb89>] do_lookup+0x279/0x2f0

while 3.1-rc has

[<f8955ec8>] btrfs_lookup+0x18/0x60 [btrfs]
[<c112ddaf>] d_inode_lookup.clone.9+0x1f/0x50
[<c113008b>] do_lookup+0x31b/0x360



Anyway, since 3.1-rc9 works I'll stick with this for now. Thanks for
your help, David.

-- 
Fajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to