Re: [regression] [v3.14] btrfs hangs while reading some files

[Ronald <ronald645@gmail.com>]

Forgot to mention that these btrfs partitions reside on an LVM.

2014-05-11 7:56 GMT+02:00 Ronald <ronald645@gmail.com>:
> Dear btrfs developers,
>
> Since v3.14, it has occasionally hapenned that reading some files from
> a btrfs partition cause the process to hang. Right, a file has been
> located that exhibits this behaviour.
>
> /home/gebruiker/.wine_office/drive_c/MSOCache/All
> Users/{90120000-0030-0000-0000-0000000FF1CE}-C/EnterWW.cab
>
> This is what happens on v3.13:
>
> 08:46 gebruiker@delta ~ :)
>  ==> FILE="$(cat fail)"
> 08:46 gebruiker@delta ~ :)
>  ==> dd if="$FILE" of=/dev/zero
> 517229+1 records in
> 517229+1 records out
> 264821640 bytes (265 MB) copied, 7.57866 s, 34.9 MB/s
>
> This is what happens on v3.14:
>
> 08:46 gebruiker@delta ~ :)
>  ==> FILE="$(cat fail)"
> 08:46 gebruiker@delta ~ :)
>  ==> dd if="$FILE" of=/dev/zero
> Killed
>
> Eventually the process is killed by me, as nothing sems to be
> hapenning. What I know is the following:
>
> - the bug has thus far consistently reproduced
> - appears to happen mostly to big files (e.g. hundreds of megs or
> several gigabyte's)
> - probably only happens when reading files from a btrfs partition
>
> An attempt to bisect has been performed:
> # bad: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14
> # good: [d8ec26d7f8287f5788a494f56e8814210f0e64be] Linux 3.13
> git bisect start 'v3.14' 'v3.13' '--' 'fs/btrfs'
> # good: [bd0330ad2174d1a5f762eee2ee58f0148f10d575] btrfs: Add acl mount option.
> git bisect good bd0330ad2174d1a5f762eee2ee58f0148f10d575
> # skip: [95def2ede1a9dd12b164932eaf5fefb67aefc41c] Btrfs: fix to catch
> all errors when resolving indirect ref
> git bisect skip 95def2ede1a9dd12b164932eaf5fefb67aefc41c
> # skip: [49fc647a2c558862145357f3a25892248042f6fe] Btrfs: do not
> export ulist functions
> git bisect skip 49fc647a2c558862145357f3a25892248042f6fe
> # skip: [3a6d75e846224542151e9ff186cb89df5a6ca2c6] Btrfs: fix qgroup
> rescan to work with skinny metadata
> git bisect skip 3a6d75e846224542151e9ff186cb89df5a6ca2c6
> # skip: [4c7a6f74ceeafd738b55d1c57349327f7ea8e895] Btrfs: rework ulist
> with list+rb_tree
> git bisect skip 4c7a6f74ceeafd738b55d1c57349327f7ea8e895
> # bad: [f568849edac8611d603e00bd6cbbcfea09395ae6] Merge branch
> 'for-3.14/core' of git://git.kernel.dk/linux-block
> git bisect bad f568849edac8611d603e00bd6cbbcfea09395ae6
> # good: [bf3d846b783327359ddc4bd4f52627b36abb4d1d] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
> git bisect good bf3d846b783327359ddc4bd4f52627b36abb4d1d
> # skip: [4f024f3797c43cb4b73cd2c50cec728842d0e49e] block: Abstract out
> bvec iterator
> git bisect skip 4f024f3797c43cb4b73cd2c50cec728842d0e49e
> # skip: [33879d4512c021ae65be9706608dacb36b4687b1] block:
> submit_bio_wait() conversions
> git bisect skip 33879d4512c021ae65be9706608dacb36b4687b1
> # skip: [bc1e79acc13d70c5bb1b2a47bf0a580e6ae81fb6] block: fixup for
> generic bio chaining
> git bisect skip bc1e79acc13d70c5bb1b2a47bf0a580e6ae81fb6
> # good: [b28bc9b38c52f63f43e3fd875af982f2240a2859] Merge tag
> 'v3.13-rc6' into for-3.14/core
> git bisect good b28bc9b38c52f63f43e3fd875af982f2240a2859
> # bad: [c7b22bb19a24fef1a851a41e5c0657c0c4a41550] btrfs: fix missing
> increment of bi_remaining
> git bisect bad c7b22bb19a24fef1a851a41e5c0657c0c4a41550
> # first bad commit: [c7b22bb19a24fef1a851a41e5c0657c0c4a41550] btrfs:
> fix missing increment of bi_remaining
>
> Reverting this commit causes the resulting kernel to OOPS during boot.
> Furthermore, the first batch of skipping is because this kernel would
> not load (grub keeps displaying 'Loading 'ArchLinux''. The second
> batch of skipping is because the resulting kernel would OOPS during
> boot.
>
> The bisect failed, since the attempt to boot the latest marked good
> kernel ended in an OOPS. So, testing this was not reliable.
>
> The machine is an 32bit UP box. ~10,5 years old. This bug has also
> been observed on multicore 64bit machines.
>
> Would appreciate some pointers on how to debug this further.
>
>                                    Ronald