linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [regression] [v3.14] btrfs hangs while reading some files
@ 2014-05-11  5:56 Ronald
  2014-05-11  6:12 ` Ronald
  0 siblings, 1 reply; 3+ messages in thread
From: Ronald @ 2014-05-11  5:56 UTC (permalink / raw)
  To: linux-btrfs

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [regression] [v3.14] btrfs hangs while reading some files
  2014-05-11  5:56 [regression] [v3.14] btrfs hangs while reading some files Ronald
@ 2014-05-11  6:12 ` Ronald
  2014-05-31  5:55   ` Ronald
  0 siblings, 1 reply; 3+ messages in thread
From: Ronald @ 2014-05-11  6:12 UTC (permalink / raw)
  To: linux-btrfs

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [regression] [v3.14] btrfs hangs while reading some files
  2014-05-11  6:12 ` Ronald
@ 2014-05-31  5:55   ` Ronald
  0 siblings, 0 replies; 3+ messages in thread
From: Ronald @ 2014-05-31  5:55 UTC (permalink / raw)
  To: linux-btrfs

Is there anything else I can do? I still have the file and should be
able to provide more data if needed.

2014-05-11 8:12 GMT+02:00 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-05-31  5:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-11  5:56 [regression] [v3.14] btrfs hangs while reading some files Ronald
2014-05-11  6:12 ` Ronald
2014-05-31  5:55   ` Ronald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).