3.2-rc4: scrubbing locks up the kernel, then hung tasks on boot

DISCUSSION Martin Steigerwald 5 participants 24 messages Dec 17, 2011 – Mar 19, 2012 Btrfs file system

Share & tools

Martin Steigerwald

author

2011-12-17 17:33 UTC #0 lore raw

Hi!

=46inally I tried scrubbing the / BTRFS filesystem mentioned in the thr= ead=20
"speeding up slow btrfs filesystem". However the machine looks up hard=20 then. It repeats the last few seconds of audio all over again, no mouse= =20
and no ssh connection anymore:

deepdance:~> btrfs scrub start /=20
scrub started on /, fsid [=E2=80=A6] (pid=3D5737)
deepdance:~> Write failed: Broken pipe

After the second attempt of doing this the machine stops on booting aft= er=20
the space cache enabled message. Then I get backtraced of hung tasks:

http://martin-steigerwald.de/tmp/btrfs/2011-17-12-deepdance-hang-at-boo=
t/

I am able to mount the filesystem from grml 2011.12-rc1 with 3.1 kernel= :

root@grml ~ # Start lvm2
Setting up LVM Volume Groups Reading all physical volumes. This may t= ake=20
a while...
Found volume group "deepdance" using metadata type lvm2
3 logical volume(s) in volume group "deepdance" now active
=2E
root@grml ~ # mount /mnt/debian
root@grml ~ # mount /mnt/home
root@grml ~ # dmesg | tail

[   55.479303] Installing knfsd (copyright (C) 1996 [email protected]).
[   64.352088] eth0: no IPv6 routers present
[   75.744318] fuse init (API version 7.17)
[   75.801245] ipmi message handler version 39.2
[   90.213880] end_request: I/O error, dev fd0, sector 0
[  229.117153] Btrfs loaded
[  229.117962] device label debian devid 1 transid 201769=20
/dev/mapper/deepdance-debian
[  229.577244] btrfs: disk space caching is enabled
[  245.375875] device label home devid 1 transid 72021=20
/dev/mapper/deepdance-home
[  245.433137] btrfs: disk space caching is enabled

root@grml ~ # umount /mnt/{debian,home}

root@grml ~ # cat /proc/version
Linux version 3.1.0-2-grml-486 (Debian 3.1.0-2+grml.3) ([email protected]) (g= cc=20
version 4.6.2 (Debian 4.6.2-5) ) #1 Fri Dec 9 00:25:07 UTC 2011

But after that 3.2-rc4 still doesn=C2=B4t boot.

I am now trying to install a 3.1.0 debian kernel via chroot.

Ok, after installing the 3.1.0 kernel it seems to work with 3.2.0-rc4 a= s=20
well again. Its again converting the old style inodes. Thus I think on = a=20
sudden crash there may be an issue with the inode cache in 3.2-rc4 that= =20
switching to 3.1.0, writing something, and then back to 3.2.0-rc4 works= =20
around.

But then I had this after upgrading from 3.0 to 3.2-rc4 as well. I didn= =C2=B4t=20
report it here cause I thought it was a one-time issue.

Hopefully you can make something out of the backtraces I tried to snaps= hot=20
with my digicam.

Should I be concerned about the state of the filesystem?

I will not try scrubbing it again for now ;)

BTW the performance of the BTRFS fs while updating the inode cache is=20 abysmal. The machine is trying to boot for about 5 minutes now and stil= l=20
no KDM to see. Hmm, at least there is an SSH now. No nothing about thes= e=20
hard lock ups in syslog as I have suspected.

Thanks,
--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2011-12-17 18:11 UTC #1 lore raw

Am Samstag, 17. Dezember 2011 schrieb Martin Steigerwald:

Quoted 5 lines

Hi!
=20
Finally I tried scrubbing the / BTRFS filesystem mentioned in the thread "speeding up slow btrfs filesystem". However the machine looks up hard then. It repeats the last few seconds of audio all over again=

Quoted 5 lines

no mouse and no ssh connection anymore:
=20
deepdance:~> btrfs scrub start /
scrub started on /, fsid [=E2=80=A6] (pid=3D5737)
deepdance:~> Write failed: Broken pipe

=46WIW the T520 can scrub its / BTRFS successfully.

merkaba:~> btrfs scrub status /
scrub status for [=E2=80=A6]

        scrub started at Sat Dec 17 18:34:49 2011 and finished after 82=

=20
seconds
total bytes scrubbed: 13.62GB with 0 errors

--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2011-12-20 20:46 UTC #2 lore raw

In reply to Martin Steigerwald

Hi again!

Any hints about this one?

Since scrubbing worked okay on other machines, I can also redo the BTRF= S=20
filesystem on this machine. Maybe it really has gained a corruption. (S= till=20
scrubbing should not lock up the kernel hard, but=E2=80=A6)

Thanks,
Martin

Am Samstag, 17. Dezember 2011 schrieb Martin Steigerwald:

Quoted 5 lines

Hi!
=20
Finally I tried scrubbing the / BTRFS filesystem mentioned in the thread "speeding up slow btrfs filesystem". However the machine looks up hard then. It repeats the last few seconds of audio all over again=

Quoted 4 lines

no mouse and no ssh connection anymore:
=20
deepdance:~> btrfs scrub start /
scrub started on /, fsid [=E2=80=A6] (pid=3D5737)

Quoted 8 lines

deepdance:~> Write failed: Broken pipe
=20
=20
After the second attempt of doing this the machine stops on booting after the space cache enabled message. Then I get backtraced of hung tasks:
=20
http://martin-steigerwald.de/tmp/btrfs/2011-17-12-deepdance-hang-at-b=

Quoted 15 lines

t/
=20
=20
I am able to mount the filesystem from grml 2011.12-rc1 with 3.1 kernel:
=20
root@grml ~ # Start lvm2
Setting up LVM Volume Groups Reading all physical volumes. This may take a while...
Found volume group "deepdance" using metadata type lvm2 3 logical volume(s) in volume group "deepdance" now active
.
root@grml ~ # mount /mnt/debian
root@grml ~ # mount /mnt/home
root@grml ~ # dmesg | tail

Quoted 1 line

[   55.479303] Installing knfsd (copyright (C) 1996 [email protected]=

Quoted 11 lines

[   64.352088] eth0: no IPv6 routers present
[   75.744318] fuse init (API version 7.17)
[   75.801245] ipmi message handler version 39.2
[   90.213880] end_request: I/O error, dev fd0, sector 0
[  229.117153] Btrfs loaded
[  229.117962] device label debian devid 1 transid 201769
/dev/mapper/deepdance-debian
[  229.577244] btrfs: disk space caching is enabled
[  245.375875] device label home devid 1 transid 72021
/dev/mapper/deepdance-home
[  245.433137] btrfs: disk space caching is enabled

Quoted 13 lines

root@grml ~ # umount /mnt/{debian,home}
=20
root@grml ~ # cat /proc/version
Linux version 3.1.0-2-grml-486 (Debian 3.1.0-2+grml.3) ([email protected]) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 Fri Dec 9 00:25:07 UTC 2011 =20
=20
But after that 3.2-rc4 still doesn=C2=B4t boot.
=20
I am now trying to install a 3.1.0 debian kernel via chroot. =20
Ok, after installing the 3.1.0 kernel it seems to work with 3.2.0-rc4 as well again. Its again converting the old style inodes. Thus I thin=

Quoted 12 lines

on a sudden crash there may be an issue with the inode cache in 3.2-rc4 that switching to 3.1.0, writing something, and then back to 3.2.0-rc4 works around.
=20
But then I had this after upgrading from 3.0 to 3.2-rc4 as well. I didn=C2=B4t report it here cause I thought it was a one-time issue. =20
Hopefully you can make something out of the backtraces I tried to snapshot with my digicam.
=20
Should I be concerned about the state of the filesystem? =20

Quoted 8 lines

I will not try scrubbing it again for now ;)
=20
BTW the performance of the BTRFS fs while updating the inode cache is abysmal. The machine is trying to boot for about 5 minutes now and still no KDM to see. Hmm, at least there is an SSH now. No nothing about these hard lock ups in syslog as I have suspected. =20
Thanks,

Martin Steigerwald

author

2012-01-21 10:49 UTC #3 lore raw

Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:

Quoted 1 line

Hi again!

[=E2=80=A6]

Quoted 5 lines

Am Samstag, 17. Dezember 2011 schrieb Martin Steigerwald:
Quoted 4 lines
Hi!
=20
Finally I tried scrubbing the / BTRFS filesystem mentioned in the thread "speeding up slow btrfs filesystem". However the machine loo=

Quoted 10 lines

Quoted 10 lines
up hard then. It repeats the last few seconds of audio all over again, no mouse and no ssh connection anymore:
=20
deepdance:~> btrfs scrub start /
scrub started on /, fsid [=E2=80=A6] (pid=3D5737) deepdance:~> Write failed: Broken pipe
=20
=20
After the second attempt of doing this the machine stops on booting after the space cache enabled message. Then I get backtraced of hun=

Quoted 3 lines

Quoted 3 lines
tasks:
=20
http://martin-steigerwald.de/tmp/btrfs/2011-17-12-deepdance-hang-at=

-b

Quoted 5 lines

Quoted 5 lines
oot/
=20
=20
I am able to mount the filesystem from grml 2011.12-rc1 with 3.1 kernel:

I still have this with 3.2.0-1-pae - which is a debian kernel based on=20 3.2.1.

When I do btrfs scrub start / the machine locks immediately up hard.

Then usually on next boot it stops on space_cache enabled message, but = not=20
the one for /, but the one for /home which is mounted later.

When I then boot with 3.1 it works. BTRFS redos the space_cache then wh= ile=20
the machine takes ages to boot - I mean ages - 10 minutes till KDM prom= pt=20
is no problem there.

I thought I just mention it here.

Since I got no hints on what to do, I probably redo both filesystems on=
the=20
machine. Should that not work out, I switch the box to Ext4.

btrfs filesystem scrub works on my ThinkPad T520 with 64-bit debian and= =20
Intel SSD 320 and one 2,5 inch external drive as well as a 3,5 inch=20 external backup drive both via eSATA, so this seems to be no principal=20 issue. It also works on a workstation at work which has 32-bit debian a= s=20
well.

Martin Steigerwald

author

2012-01-21 11:19 UTC #4 lore raw

Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:

Quoted 1 line

I still have this with 3.2.0-1-pae - which is a debian kernel based o=

n=20

Quoted 5 lines

3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately up hard. =20
Then usually on next boot it stops on space_cache enabled message, bu=

Quoted 5 lines

not the one for /, but the one for /home which is mounted later. =20
When I then boot with 3.1 it works. BTRFS redos the space_cache then while the machine takes ages to boot - I mean ages - 10 minutes till KDM prompt is no problem there.

I now tested scrubbing /home which is a different BTRFS filesystem on t= he=20
same machine.

Then the scrub is started, scrub status tells me so, but nothing happen= s,=20
no block in/out activity in vmstat, no CPU related activity in top.

btrfs scrub cancel then hangs, but not the complete machine, only the=20 process.

I had this once on my T520 with the internal Intel SSD 320 as well. The= =20
other time it worked.

Well maybe that is due to BTRFS doing something else on my T23 now:

deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:09 [btrfs=
-
ino-cache]

Hmmm, so I just let it sit for a while, maybe eventually it will scrub=20 /home.

At least it doesn=C2=B4t lock up hard, so there might really be somethi= ng=20
strange with /.

Martin Steigerwald

author

2012-02-24 15:51 UTC #5 lore raw

Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:

Quoted 5 lines

Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 4 lines
I still have this with 3.2.0-1-pae - which is a debian kernel based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately up hard=

=2E

Quoted 6 lines

Quoted 6 lines
=20
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home which is mounted later.
=20
When I then boot with 3.1 it works. BTRFS redos the space_cache the=

Quoted 1 line

Quoted 1 line
while the machine takes ages to boot - I mean ages - 10 minutes ti=

Quoted 13 lines

Quoted 1 line
KDM prompt is no problem there.
=20
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CPU related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, only the process.
=20
I had this once on my T520 with the internal Intel SSD 320 as well. T=

Quoted 9 lines

other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T23 now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:09
[btrfs- ino-cache]
=20
Hmmm, so I just let it sit for a while, maybe eventually it will scru=

Quoted 3 lines

/home.
=20
At least it doesn=C2=B4t lock up hard, so there might really be somet=

hing

Quoted 1 line

strange with /.

=46WIW a btrfs filesystem balance / does work. After this a btrfs scrub=
start=20
/ still locks the kernel.

Anyway, I might be waiting for the new fsck and try it on the partition= =2E=20
Or redo the filesystem from scratch, cause I think trying to debug this= =20
will take way more time.

I might also as well redo /home as well. Two fresh 3.2 or 3.3 kernel BT= RFS=20
and see whether they work better.

Arne Jansen

2012-02-25 08:14 UTC #6 lore raw

Hi Martin,

I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?

Thanks,
Arne

Quoted 6 lines · Martin Steigerwald

Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 5 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 4 lines
I still have this with 3.2.0-1-pae - which is a debian kernel based on 3.2.1.
When I do btrfs scrub start / the machine locks immediately up hard=

=2E

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home which is mounted later.
When I then boot with 3.1 it works. BTRFS redos the space_cache the=

Quoted 1 line

Quoted 1 line
Quoted 1 line
while the machine takes ages to boot - I mean ages - 10 minutes ti=

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
KDM prompt is no problem there.
I now tested scrubbing /home which is a different BTRFS filesystem o=

Quoted 7 lines

Quoted 7 lines
the same machine.
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CPU related activity in top.
btrfs scrub cancel then hangs, but not the complete machine, only th=

Quoted 3 lines

Quoted 3 lines
process.
I had this once on my T520 with the internal Intel SSD 320 as well. =

The

Quoted 9 lines

Quoted 9 lines
other time it worked.
Well maybe that is due to BTRFS doing something else on my T23 now:
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:09
[btrfs- ino-cache]
Hmmm, so I just let it sit for a while, maybe eventually it will scr=

Quoted 3 lines

Quoted 3 lines
/home.
At least it doesn=C2=B4t lock up hard, so there might really be some=

thing

Quoted 3 lines

Quoted 1 line
strange with /.
FWIW a btrfs filesystem balance / does work. After this a btrfs scrub=

start

Quoted 3 lines

/ still locks the kernel.
Anyway, I might be waiting for the new fsck and try it on the partiti=

on.

Quoted 1 line

Or redo the filesystem from scratch, cause I think trying to debug th=

Quoted 3 lines

will take way more time.
I might also as well redo /home as well. Two fresh 3.2 or 3.3 kernel =

BTRFS

Quoted 2 lines

and see whether they work better.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2012-02-25 20:14 UTC #7 lore raw

Am Samstag, 25. Februar 2012 schrieb Arne Jansen:

Quoted 4 lines

Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?

I saved them and I try to. But no promises as to when. The machine is s= low=20
at compiling kernels. And there are two annoying Pulseaudio issues I=C2= =B4d=20
like to take time to gather more infos about that Pulseaudio developers= =20
requested. So there is some sort of a backlog.

Ciao,
--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2012-03-15 17:32 UTC #8 lore raw

In reply to Arne Jansen

Am Samstag, 25. Februar 2012 schrieb Arne Jansen:

Quoted 4 lines · Martin Steigerwald

Quoted 3 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 1 line
I still have this with 3.2.0-1-pae - which is a debian kernel bas=

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately up hard.
=20
Then usually on next boot it stops on space_cache enabled message=

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
but not the one for /, but the one for /home which is mounted later.
=20
When I then boot with 3.1 it works. BTRFS redos the space_cache then while the machine takes ages to boot - I mean ages - 10 minutes till KDM prompt is no problem there.

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
=20
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CPU related activi=

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, only the process.
=20
I had this once on my T520 with the internal Intel SSD 320 as well=

=2E

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T23 now=

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:09
[btrfs- ino-cache]
=20
Hmmm, so I just let it sit for a while, maybe eventually it will scrub /home.
=20
At least it doesn=C2=B4t lock up hard, so there might really be so=

mething

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a btrfs scr=

Quoted 6 lines

Quoted 1 line
start / still locks the kernel.
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?

I didn=C2=B4t yet test it but I tried the first balance then scrub stuf= f again:

deepdance:~> btrfs filesystem balance /

This time scrub didn=C2=B4t lock up hard:

deepdance:~> btrfs scrub start /
scrub started on /, fsid 2bf5b1dc-1d89-4f0d-a561-1a5551a27275 (pid=3D33=
47)
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 10 secon=

ds
total bytes scrubbed: 272.59MB with 0 errors
deepdance:~> cat /proc/version
Linux version 3.2.0-1-686-pae (Debian 3.2.6-1) ([email protected]) (gcc version 4.6.2 (Debian 4.6.2-14) ) #1 SMP Fri Feb 17 06:27:21 UTC 2= 012
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 55 secon=

ds
total bytes scrubbed: 1.29GB with 0 errors
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 175 seco=

nds
total bytes scrubbed: 2.58GB with 0 errors

But it seems to be stuck now:

deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 295 seco=

nds
total bytes scrubbed: 2.58GB with 0 errors
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 395 seco=

nds
total bytes scrubbed: 2.58GB with 0 errors
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Thu Mar 15 18:10:52 2012, running for 636 seco=

nds
total bytes scrubbed: 2.58GB with 0 errors

There is almost no activity in vmstat 5:

2 0 108812 63812 36 412716 0 22 0 437 515 1723 47 13=
37 3
2 0 108812 63320 36 413168 0 0 81 0 453 1600 44 12=
43 1
2 0 108812 68056 36 413512 0 0 64 0 480 1589 51 11=
38 0
2 0 108812 68112 36 413516 0 0 0 0 460 1454 46 11=
43 0
1 0 108812 68112 36 413536 0 0 0 1 454 1456 45 11=
44 0
1 1 108812 67924 36 413692 0 0 0 330 491 1578 49 13=
37 1
2 0 108812 67808 36 413792 0 0 0 6 473 1556 48 11=
41 0
2 0 108812 67436 36 414124 0 0 0 424 523 1922 47 13=
39 2
1 0 108812 67460 36 414136 0 0 0 0 453 1578 46 9=
45 0
2 0 108812 67476 36 414136 0 0 0 0 465 1493 46 12=
41 0
procs -----------memory---------- ---swap-- -----io---- -system-- ----c= pu----
r b swpd free buff cache si so bi bo in cs us sy=
id wa
3 0 108812 67492 36 414140 0 0 0 0 467 1609 48 10=
42 0
2 0 108812 67500 36 414148 0 0 0 0 470 1686 46 12=
41 0
1 0 108812 66872 36 414152 0 0 0 1 463 1585 46 11=
43 0
1 0 108812 67492 36 414156 0 0 0 1 483 1612 48 13=
39 0
2 0 108812 67428 36 414156 0 0 0 325 497 1654 48 9=
41 1
0 0 108812 67452 36 414160 0 0 0 3 478 1588 46 15=
39 0
2 0 108812 65840 36 415228 0 0 214 0 465 1408 54 10=
36 0
0 0 108812 66124 36 415352 0 0 24 0 510 1476 62 14=
22 2

Given the general slowness of the machine, I waited about 15 seconds on=
a

tail -f /var/log/syslog

while just a Konsole and Amarok was running and wait about that time or even longer when logging via SSH at times, I think next I try newest Debian kernel which should be up to 3.2.10.

If that doesn=C2=B4t work, I consider trying your patches.

At least its a step forward: The machine doesn=C2=B4t lock up hard anym= ore. Its
still playing music.

=46WIW a cancel hangs:

deepdance:~> btrfs scrub cancel /

martin@deepdance:~> ps aux | grep btrfs | grep cancel
root 3429 0.0 0.0 2128 304 pts/5 D+ 18:24 0:00 btrfs =
scrub cancel /

Ah, now there we go, from dmesg:

16453.391004] btrfs: relocating block group 41393586176 flags 1

[16568.504524] btrfs: found 9891 extents
[16660.810000] btrfs: found 9891 extents
[16664.818271] btrfs: relocating block group 40319844352 flags 1
[16729.029078] btrfs: found 3593 extents
[16755.771257] btrfs: found 3593 extents
[16757.816472] btrfs: relocating block group 39246102528 flags 1
[16843.042862] btrfs: found 13147 extents
[16898.078594] btrfs: found 13147 extents
[16905.444650] btrfs: relocating block group 39237713920 flags 34
[16910.579963] btrfs: found 1 extents
[16915.946553] btrfs: relocating block group 39103496192 flags 36
[16997.308374] btrfs: found 14552 extents
[17002.239868] btrfs: relocating block group 38969278464 flags 36
[17165.253567] btrfs: found 22792 extents
[17166.522513] btrfs: relocating block group 38835060736 flags 36
[17376.519168] btrfs: found 22857 extents
[17377.526508] btrfs: relocating block group 38700843008 flags 36
[17559.413243] btrfs: found 24810 extents
[17563.767590] btrfs: relocating block group 37627101184 flags 1
[17646.272226] btrfs: found 10900 extents
[17694.323897] btrfs: found 10900 extents
[17697.171187] btrfs: relocating block group 36553359360 flags 1
[17779.364231] btrfs: found 12149 extents
[17828.395574] btrfs: found 12149 extents
[17831.593055] btrfs: relocating block group 35479617536 flags 1
[17923.352624] btrfs: found 22174 extents
[18014.147595] btrfs: found 22174 extents
[18015.821756] btrfs: relocating block group 35345399808 flags 36
[18055.201043] btrfs: found 9166 extents
[18061.692337] btrfs: relocating block group 34271657984 flags 1
[18173.986306] btrfs: found 29124 extents
[18328.733328] btrfs: found 29124 extents
[18333.141061] btrfs: relocating block group 33197916160 flags 1
[18427.523898] btrfs: found 26881 extents
[18587.015489] btrfs: found 26880 extents
[18590.183797] btrfs: relocating block group 33063698432 flags 36
[18590.183797] btrfs: relocating block group 33063698432 flags 36
[18624.883576] btrfs: found 6522 extents
[18628.618415] btrfs: relocating block group 32929480704 flags 36
[18670.147756] btrfs: found 9876 extents
[18671.426925] btrfs: relocating block group 32795262976 flags 36
[18863.313381] btrfs: found 27324 extents
[18864.392712] btrfs: relocating block group 31721521152 flags 1
[18945.941315] btrfs: found 21748 extents
[19076.164135] btrfs: found 21721 extents
[20880.564211] INFO: task btrfs:3348 blocked for more than 120 seconds.
[20880.564225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disab=
les this message.
[20880.564234] btrfs           D 000012d2     0  3348      1 0x00000000
[20880.564251]  c0b72080 00000086 2cae1a17 000012d2 ec3ae5a0 00000000 0=
00012d2 c14769c0
[20880.564275]  c0b7222c c14769c0 00008050 e0b96ce0 ee000120 d1d5dae0 d=
1d5db20 00000028
[20880.564298]  c105d451 00000092 c12b949b 00000092 f0b7037c 00000246 e=
ee6073c c105d451
[20880.564321] Call Trace:
[20880.564348]  [<c105d451>] ? arch_local_irq_save+0xf/0x14
[20880.564368]  [<c12b949b>] ? _raw_spin_lock_irqsave+0x8/0x21
[20880.564482]  [<f0b7037c>] ? btrfs_queue_worker+0x1cd/0x1fc [btrfs]
[20880.564497]  [<c105d451>] ? arch_local_irq_save+0xf/0x14
[20880.564511]  [<c12b949b>] ? _raw_spin_lock_irqsave+0x8/0x21
[20880.564526]  [<c104d402>] ? prepare_to_wait+0x12/0x50
[20880.564601]  [<f0b8a8c8>] ? btrfs_reada_wait+0x5b/0x84 [btrfs]
[20880.564615]  [<c104d4d0>] ? add_wait_queue+0x30/0x30
[20880.564687]  [<f0b87e33>] ? scrub_stripe+0x34c/0xbda [btrfs]
[20880.564729]  [<f0a4da1f>] ? scsi_alloc_sgtable+0x1a/0x38 [scsi_mod]
[20880.564786]  [<f0b37a7f>] ? comp_keys+0x2f/0x34 [btrfs]
[20880.564842]  [<f0b37b4d>] ? generic_bin_search.constprop.31+0xc9/0x1=
04 [btrfs]
[20880.564856]  [<c104d4d0>] ? add_wait_queue+0x30/0x30
[20880.564912]  [<f0b37bbf>] ? bin_search+0x37/0x3d [btrfs]
[20880.564987]  [<f0b5e3d4>] ? __lookup_extent_mapping+0xe5/0x101 [btrf=
s]
[20880.565061]  [<f0b88781>] ? scrub_chunk.isra.13+0xc0/0xef [btrfs]
[20880.565134]  [<f0b889a3>] ? scrub_enumerate_chunks+0x1f3/0x23a [btrf=
s]
[20880.565209]  [<f0b89486>] ? btrfs_scrub_dev+0x215/0x34e [btrfs]
[20880.565230]  [<c10c061a>] ? __kmalloc_track_caller+0x9b/0xa7
[20880.565248]  [<c102a280>] ? should_resched+0x5/0x1e
[20880.565320]  [<f0b74b14>] ? btrfs_ioctl+0xc55/0xda1 [btrfs]
[20880.565335]  [<c1029188>] ? kmap_atomic_prot+0x2f/0xe0
[20880.565353]  [<c10ad3d5>] ? handle_mm_fault+0x1ee/0x1fd
[20880.565426]  [<f0b73ebf>] ? btrfs_ioctl_trans_end+0x49/0x49 [btrfs]
[20880.565442]  [<c10d7023>] ? do_vfs_ioctl+0x459/0x48f
[20880.565457]  [<c12bc3d7>] ? do_page_fault+0x2e0/0x2fc
[20880.565469]  [<c12bc3c4>] ? do_page_fault+0x2cd/0x2fc
[20880.565484]  [<c10d709d>] ? sys_ioctl+0x44/0x67
[20880.565499]  [<c12bdd1f>] ? sysenter_do_call+0x12/0x28
[21000.564277] INFO: task btrfs:3348 blocked for more than 120 seconds.
[21000.564292] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disab=
les this message.
[21000.564302] btrfs           D 000012d2     0  3348      1 0x00000000
[21000.564319]  c0b72080 00000086 2cae1a17 000012d2 ec3ae5a0 00000000 0=
00012d2 c14769c0
[21000.564344]  c0b7222c c14769c0 00008050 e0b96ce0 ee000120 d1d5dae0 d=
1d5db20 00000028
[21000.564366]  c105d451 00000092 c12b949b 00000092 f0b7037c 00000246 e=
ee6073c c105d451
[21000.564390] Call Trace:
[21000.564422]  [<c105d451>] ? arch_local_irq_save+0xf/0x14
[21000.564442]  [<c12b949b>] ? _raw_spin_lock_irqsave+0x8/0x21
[21000.564582]  [<f0b7037c>] ? btrfs_queue_worker+0x1cd/0x1fc [btrfs]
[21000.564600]  [<c105d451>] ? arch_local_irq_save+0xf/0x14
[21000.564614]  [<c12b949b>] ? _raw_spin_lock_irqsave+0x8/0x21
[21000.564630]  [<c104d402>] ? prepare_to_wait+0x12/0x50
[21000.564707]  [<f0b8a8c8>] ? btrfs_reada_wait+0x5b/0x84 [btrfs]
[21000.564721]  [<c104d4d0>] ? add_wait_queue+0x30/0x30
[21000.564793]  [<f0b87e33>] ? scrub_stripe+0x34c/0xbda [btrfs]
[21000.564840]  [<f0a4da1f>] ? scsi_alloc_sgtable+0x1a/0x38 [scsi_mod]
[21000.564899]  [<f0b37a7f>] ? comp_keys+0x2f/0x34 [btrfs]
[21000.564954]  [<f0b37b4d>] ? generic_bin_search.constprop.31+0xc9/0x1=
04 [btrfs]
[21000.564968]  [<c104d4d0>] ? add_wait_queue+0x30/0x30
[21000.565024]  [<f0b37bbf>] ? bin_search+0x37/0x3d [btrfs]
[21000.565099]  [<f0b5e3d4>] ? __lookup_extent_mapping+0xe5/0x101 [btrf=
s]
[21000.565173]  [<f0b88781>] ? scrub_chunk.isra.13+0xc0/0xef [btrfs]
[21000.565246]  [<f0b889a3>] ? scrub_enumerate_chunks+0x1f3/0x23a [btrf=
s]
[21000.565322]  [<f0b89486>] ? btrfs_scrub_dev+0x215/0x34e [btrfs]
[21000.565345]  [<c10c061a>] ? __kmalloc_track_caller+0x9b/0xa7
[21000.565363]  [<c102a280>] ? should_resched+0x5/0x1e
[21000.565436]  [<f0b74b14>] ? btrfs_ioctl+0xc55/0xda1 [btrfs]
[21000.565451]  [<c1029188>] ? kmap_atomic_prot+0x2f/0xe0
[21000.565471]  [<c10ad3d5>] ? handle_mm_fault+0x1ee/0x1fd
[21000.565544]  [<f0b73ebf>] ? btrfs_ioctl_trans_end+0x49/0x49 [btrfs]
[21000.565561]  [<c10d7023>] ? do_vfs_ioctl+0x459/0x48f
[21000.565577]  [<c12bc3d7>] ? do_page_fault+0x2e0/0x2fc
[21000.565589]  [<c12bc3c4>] ? do_page_fault+0x2cd/0x2fc
[21000.565603]  [<c10d709d>] ? sys_ioctl+0x44/0x67
[21000.565619]  [<c12bdd1f>] ? sysenter_do_call+0x12/0x28

[=E2=80=A6 it seems to go on this way =E2=80=A6]

Maybe something of that is helpful?

I leave the machine running for a while, but I think it won=C2=B4t hibe= rnate
with a process stuck in D state so eventually at some time I will shut = it
down and restart. OTOH I could leave it running till tomorrow or what.

I will put log files aside for further diagnostics in any case.

Martin Steigerwald

author

2012-03-15 17:39 UTC #9 lore raw

Am Donnerstag, 15. M=C3=A4rz 2012 schrieb Martin Steigerwald:

Quoted 7 lines

[20880.564225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message. [20880.564234] btrfs           D
000012d2     0  3348      1 0x00000000 [20880.564251]  c0b72080
00000086 2cae1a17 000012d2 ec3ae5a0 00000000 000012d2 c14769c0
[20880.564275]  c0b7222c c14769c0 00008050 e0b96ce0 ee000120 d1d5dae0

d1d5db20 00000028 [20880.564298] c105d451 00000092 c12b949b 00000092 f0b7037c 00000246 eee6073c c105d451

Seems to be a thread of the btrfs scrub start process:

martin@deepdance:~/scrub-hang-2012-03-15#1> ps aux | grep "btrfs " | gr= ep -v grep=20
root 3347 0.5 0.0 18520 112 pts/5 Sl 18:10 0:08 btrfs =
scrub start /
root 3429 0.0 0.0 2128 304 pts/5 D+ 18:24 0:00 btrfs =
scrub cancel /

deepdance:/proc/3348> cat cmdline
btrfsscrubstart/# =

                                                             =20
deepdance:/proc/3348> cat sched =20
btrfs (3348, #threads: 3)
---------------------------------------------------------
se.exec_start                      :      20693902.056600
se.vruntime                        :       4558167.340245
se.sum_exec_runtime                :          8284.354850
nr_switches                        :               116554
nr_voluntary_switches              :               115784
nr_involuntary_switches            :                  770
se.load.weight                     :                 1024
policy                             :                    0
prio                               :                  120
clock-delta                        :                  563

Chris Mason

2012-03-15 17:42 UTC #10 lore raw

In reply to Martin Steigerwald

Quoted 5 lines · Martin Steigerwald

Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 4 lines · Martin Steigerwald
Quoted 3 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 1 line
I still have this with 3.2.0-1-pae - which is a debian kernel b=

ased

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately up hard.
=20
Then usually on next boot it stops on space_cache enabled messa=

ge,

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
but not the one for /, but the one for /home which is mounted later.
=20
When I then boot with 3.1 it works. BTRFS redos the space_cache then while the machine takes ages to boot - I mean ages - 10 minutes till KDM prompt is no problem there.
=20
I now tested scrubbing /home which is a different BTRFS filesyst=

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CPU related acti=

vity

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, onl=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
the process.
=20
I had this once on my T520 with the internal Intel SSD 320 as we=

ll.

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T23 n=

ow:

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:09
[btrfs- ino-cache]
=20
Hmmm, so I just let it sit for a while, maybe eventually it will scrub /home.
=20
At least it doesn=B4t lock up hard, so there might really be som=

ething

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a btrfs s=

crub

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
start / still locks the kernel.
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?
=20
I didn=B4t yet test it but I tried the first balance then scrub stuff=

again:

Looks like you're on a 32 bit machine. The current for-linus branch ha= s
an important fix for scrub on 32 bit that should solve this.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2012-03-15 18:03 UTC #11 lore raw

Am Donnerstag, 15. M=E4rz 2012 schrieb Chris Mason:

Quoted 9 lines · Martin Steigerwald

Quoted 8 lines
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 7 lines · Martin Steigerwald
Quoted 6 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 5 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 4 lines
I still have this with 3.2.0-1-pae - which is a debian kernel based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately u=

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
hard.
=20
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home which is mounted later.
=20
When I then boot with 3.1 it works. BTRFS redos the space_cac=

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
then while the machine takes ages to boot - I mean ages - 10 minutes till KDM prompt is no problem there.
=20
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothi=

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
happens, no block in/out activity in vmstat, no CPU related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, only the process.
=20

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
I had this once on my T520 with the internal Intel SSD 320 as well. The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T23 now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
[btrfs- ino-cache]
=20
Hmmm, so I just let it sit for a while, maybe eventually it wi=

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
scrub /home.
=20
At least it doesn=B4t lock up hard, so there might really be something strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a btrfs scrub start / still locks the kernel.

Quoted 7 lines

Quoted 7 lines
Quoted 5 lines
=20
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?
=20
I didn=B4t yet test it but I tried the first balance then scrub stu=

ff=20

Quoted 3 lines

Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus branch has an important fix for scrub on 32 bit that should solve this.

Yes, thats 32-bit.

Can this fix be applied to 3.2 as well? If yes, could you point me at i= t?
Or otherwise is current for-linus somewhat stable?

Cloning nonetheless - well after it finally installed git there which takes ages with audio playback lockups. Hopefully the /home BTRFS is faster than the / one ;). I have no cross-compiling set up.

=46rom atop:

=46rom vmstat 1:

deepdance:~> vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----c= pu----
r b swpd free buff cache si so bi bo in cs us sy=
id wa
0 2 127012 109472 36 263096 1 6 661 740 516 1572 42 14=
41 4
0 2 127012 110628 36 263088 0 0 0 2228 995 2114 41 14=
0 44
0 0 127012 112800 36 263088 0 0 0 2916 1148 2306 38 19=
2 41
1 0 127012 98416 36 277192 664 0 664 8 642 1203 82 13=
3 2
2 0 127012 79320 36 294872 1072 0 1072 0 653 1226 77 16=
0 7
9 0 127556 85952 36 279968 700 544 700 16456 1442 9767 37 63=
0 0
3 0 127556 92584 36 281720 360 0 364 22408 1743 11684 44 5=
6 0 0
0 2 127556 90964 36 282984 0 0 52 3104 915 2528 41 44=
0 14
3 1 127556 91932 36 283036 0 0 0 2408 995 1969 46 14=
0 40
0 1 127556 91760 36 283296 0 0 4 3004 980 2140 39 27=
6 29
6 1 121000 190288 36 283884 0 0 612 8 596 1452 39 17=
26 18
1 2 121000 181060 36 287732 0 0 3776 2104 791 1485 52 33=
0 15
2 2 121000 181212 36 287724 0 0 4 2384 862 1936 40 23=
1 37
0 1 121000 181444 36 287732 0 0 4 1888 870 2000 38 20=
10 32
1 0 121000 181160 36 287740 0 0 4 2104 846 2170 45 25=
9 20
3 1 121000 181156 36 287748 0 0 0 3528 916 2179 44 17=
7 32
0 0 121000 181748 36 287756 0 0 0 1976 843 2199 41 19=
17 23
3 0 121000 179252 36 290036 0 0 2240 2088 875 2197 42 30=
1 28

These high values on wait luck suspicious to me.

Anyway, cloning now.

Chris Mason

2012-03-15 18:08 UTC #12 lore raw

Quoted 3 lines · Martin Steigerwald

Am Donnerstag, 15. M=E4rz 2012 schrieb Chris Mason:
Quoted 2 lines
Quoted 2 lines
=20
I didn=B4t yet test it but I tried the first balance then scrub s=

tuff=20

Quoted 2 lines

Quoted 2 lines
Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus branc=

Quoted 5 lines

Quoted 1 line
has an important fix for scrub on 32 bit that should solve this.
=20
Yes, thats 32-bit.
=20
Can this fix be applied to 3.2 as well? If yes, could you point me at=

it?

Quoted 9 lines

Or otherwise is current for-linus somewhat stable?
=20
Cloning nonetheless - well after it finally installed git there which takes ages with audio playback lockups. Hopefully the /home BTRFS is faster than the / one ;). I have no cross-compiling set up. =20
From atop:
=20
PAG | scan 11903 | stall 0 | | swin 25 | swou=

t 875 |

Quoted 1 line

DSK | sda | busy 74% | read 297 | write 4240 | avio=

    1 ms |

http://git.kernel.org/?p=3Dlinux/kernel/git/mason/linux-btrfs.git;a=3Dc=
ommit;h=3Da175423c831ea582c06784d1e172d2ce1d79923a

The patch is so small you can edit it by hand.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author Tested-by

2012-03-16 15:05 UTC #13 lore raw

In reply to Chris Mason

Am Donnerstag, 15. M=C3=A4rz 2012 schrieb Chris Mason:

Quoted 9 lines · Martin Steigerwald

Quoted 8 lines
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 7 lines · Martin Steigerwald
Quoted 6 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 5 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 4 lines
I still have this with 3.2.0-1-pae - which is a debian kernel based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately u=

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
hard.
=20
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home which is mounted later.

[=E2=80=A6]

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothi=

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
happens, no block in/out activity in vmstat, no CPU related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, only the process.
=20

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
I had this once on my T520 with the internal Intel SSD 320 as well. The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T23 now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 0:=

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[btrfs- ino-cache]

[=E2=80=A6]

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
At least it doesn=C2=B4t lock up hard, so there might really b=

Quoted 11 lines

Quoted 11 lines
Quoted 9 lines
Quoted 4 lines
Quoted 1 line
something strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a btrfs scrub start / still locks the kernel.
=20
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if these fix your problem with scrub?
=20
I didn=C2=B4t yet test it but I tried the first balance then scrub =

stuff=20

Quoted 3 lines

Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus branch has an important fix for scrub on 32 bit that should solve this.

So finally - the machine did make-kpkg over night and complained about missing Documentation lguest, then I switched off lots from distro defa= ult
config and just did the usual make stuff - I was able to scrub both partitions on that ThinkPad T23:

deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275

        scrub started at Fri Mar 16 11:56:12 2012 and finished after 74=

1 seconds
total bytes scrubbed: 9.62GB with 0 errors

deepdance:~> btrfs scrub status /home
scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d

        scrub started at Fri Mar 16 12:00:31 2012 and finished after 17=

08 seconds
total bytes scrubbed: 36.63GB with 0 errors

Thanks a lot for fixing this.=20

Tested-by Martin Steigerwald <[email protected]>

Arne, if you want me to test your two patches to readahead as well, ple= ase
tell me. Now since only a few files need to be recompiled it would be quite easy to test them.

Next challenge is the slow performance at times. This morning as I boot= ed
into the new kernel afterwards on tty it took at least 15 seconds of heavy disk activity with hearable lots of seeks to just open a screen. But thats something for a different thread.

Arne Jansen

2012-03-16 15:37 UTC #14 lore raw

Quoted 17 lines · Martin Steigerwald

Quoted 1 line
has an important fix for scrub on 32 bit that should solve this.
So finally - the machine did make-kpkg over night and complained about missing Documentation lguest, then I switched off lots from distro default config and just did the usual make stuff - I was able to scrub both partitions on that ThinkPad T23:
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
scrub started at Fri Mar 16 11:56:12 2012 and finished after 741 seconds total bytes scrubbed: 9.62GB with 0 errors
deepdance:~> btrfs scrub status /home
scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d
scrub started at Fri Mar 16 12:00:31 2012 and finished after 1708 seconds total bytes scrubbed: 36.63GB with 0 errors

Quoted 7 lines

Thanks a lot for fixing this.
Tested-by Martin Steigerwald <[email protected]>
Arne, if you want me to test your two patches to readahead as well, please tell me. Now since only a few files need to be recompiled it would be quite easy to test them

As Chris's patch already solves your problem, I think we're fine. The two patches are more important for future users of readahead. As I had them sitting in the queue there was a small hope they might help your problem ;)

Thanks,
Arne

Quoted 7 lines

Next challenge is the slow performance at times. This morning as I booted into the new kernel afterwards on tty it took at least 15 seconds of heavy disk activity with hearable lots of seeks to just open a screen. But thats something for a different thread.
Thanks,

Martin Steigerwald

author

2012-03-17 09:43 UTC #15 lore raw

In reply to Martin Steigerwald

Hi Greg, Chris, Arne, hi everyone,

Am Freitag, 16. M=C3=A4rz 2012 schrieb Martin Steigerwald:

Quoted 7 lines

Am Donnerstag, 15. M=C3=A4rz 2012 schrieb Chris Mason:
Quoted 6 lines · Martin Steigerwald
Quoted 5 lines
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 4 lines · Martin Steigerwald
Quoted 3 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 1 line
I still have this with 3.2.0-1-pae - which is a debian kern=

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediately up hard.
=20
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home whic=

Quoted 15 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is mounted later.
=20
[=E2=80=A6]
=20
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CPU related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete machine, only the process.
=20
I had this once on my T520 with the internal Intel SSD 320 a=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
well. The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my T=

Quoted 9 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 =20
0:09 [btrfs- ino-cache]
=20
[=E2=80=A6]
=20
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
At least it doesn=C2=B4t lock up hard, so there might really=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
something strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a btr=

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
scrub start / still locks the kernel.
=20
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if the=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
fix your problem with scrub?
=20
I didn=C2=B4t yet test it but I tried the first balance then scru=

b stuff

Quoted 3 lines

Quoted 3 lines
=20
Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus branc=

Quoted 3 lines

Quoted 1 line
has an important fix for scrub on 32 bit that should solve this.
=20
So finally - the machine did make-kpkg over night and complained abou=

Quoted 2 lines

missing Documentation lguest, then I switched off lots from distro default config and just did the usual make stuff - I was able to scru=

Quoted 14 lines

both partitions on that ThinkPad T23:
=20
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
scrub started at Fri Mar 16 11:56:12 2012 and finished after
741 seconds total bytes scrubbed: 9.62GB with 0 errors =20
deepdance:~> btrfs scrub status /home
scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d
scrub started at Fri Mar 16 12:00:31 2012 and finished after
1708 seconds total bytes scrubbed: 36.63GB with 0 errors =20
Thanks a lot for fixing this.
=20

Quoted 1 line

Tested-by Martin Steigerwald <[email protected]>

[=E2=80=A6]

Would that patch

Btrfs: fix casting error in scrub reada code

http://git.kernel.org/?p=3Dlinux/kernel/git/mason/linux-
btrfs.git;a=3Dcommit;h=3Da175423c831ea582c06784d1e172d2ce1d79923a

(sorry for line break. KMail insists on it even when I disable line bre= aks=20
due to the minus sign in the URL.)

that I tested above be something for stable?

To my knowledge Debian Wheezy and Ubuntu 12.04 LTS will have 3.2.

Greg Kroah-Hartman

2012-03-18 00:37 UTC #16 lore raw

Quoted 5 lines · Martin Steigerwald

Hi Greg, Chris, Arne, hi everyone,
=20
Am Freitag, 16. M=C3=A4rz 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Donnerstag, 15. M=C3=A4rz 2012 schrieb Chris Mason:
Quoted 1 line
On Thu, Mar 15, 2012 at 06:32:19PM +0100, Martin Steigerwald wrot=

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 4 lines · Martin Steigerwald
Quoted 3 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 1 line
I still have this with 3.2.0-1-pae - which is a debian ke=

rnel

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immediate=

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
up hard.
=20
Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home wh=

ich

Quoted 9 lines

Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is mounted later.
=20
[=E2=80=A6]
=20
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no CP=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete machin=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
only the process.
=20
I had this once on my T520 with the internal Intel SSD 320=

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
well. The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on my=

T23

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:15 =

=20

Quoted 5 lines

Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
0:09 [btrfs- ino-cache]
=20
[=E2=80=A6]
=20
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
At least it doesn=C2=B4t lock up hard, so there might real=

ly be

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
something strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a b=

trfs

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
scrub start / still locks the kernel.
=20
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if t=

hese

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
fix your problem with scrub?
=20
I didn=C2=B4t yet test it but I tried the first balance then sc=

rub stuff

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
=20
Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus bra=

nch

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
has an important fix for scrub on 32 bit that should solve this.
=20
So finally - the machine did make-kpkg over night and complained ab=

out

Quoted 2 lines

Quoted 2 lines
missing Documentation lguest, then I switched off lots from distro default config and just did the usual make stuff - I was able to sc=

rub

Quoted 5 lines

Quoted 5 lines
both partitions on that ThinkPad T23:
=20
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
scrub started at Fri Mar 16 11:56:12 2012 and finished afte=

Quoted 5 lines

Quoted 5 lines
741 seconds total bytes scrubbed: 9.62GB with 0 errors =20
deepdance:~> btrfs scrub status /home
scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d
scrub started at Fri Mar 16 12:00:31 2012 and finished afte=

Quoted 5 lines

Quoted 5 lines
1708 seconds total bytes scrubbed: 36.63GB with 0 errors =20
Thanks a lot for fixing this.
=20
Tested-by Martin Steigerwald <[email protected]>

Quoted 10 lines

[=E2=80=A6]
=20
Would that patch
=20
Btrfs: fix casting error in scrub reada code
=20
http://git.kernel.org/?p=3Dlinux/kernel/git/mason/linux-
btrfs.git;a=3Dcommit;h=3Da175423c831ea582c06784d1e172d2ce1d79923a =20
(sorry for line break. KMail insists on it even when I disable line b=

reaks=20

Quoted 3 lines

due to the minus sign in the URL.)
=20
that I tested above be something for stable?

This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly.

</formletter>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

2012-03-19 08:31 UTC #17 lore raw

Am Sonntag, 18. M=C3=A4rz 2012 schrieb Greg Kroah-Hartman:

Quoted 6 lines · Martin Steigerwald

Quoted 5 lines
Hi Greg, Chris, Arne, hi everyone,
=20
Am Freitag, 16. M=C3=A4rz 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Donnerstag, 15. M=C3=A4rz 2012 schrieb Chris Mason:
Quoted 1 line
On Thu, Mar 15, 2012 at 06:32:19PM +0100, Martin Steigerwald wr=

ote:

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Quoted 4 lines · Martin Steigerwald
Quoted 3 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 2 lines
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Quoted 1 line
I still have this with 3.2.0-1-pae - which is a debian =

kernel

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
based on 3.2.1.
=20
When I do btrfs scrub start / the machine locks immedia=

tely

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
up hard.
=20
Then usually on next boot it stops on space_cache enabl=

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
message, but not the one for /, but the one for /home =

which

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is mounted later.
=20
[=E2=80=A6]
=20
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I now tested scrubbing /home which is a different BTRFS filesystem on the same machine.
=20
Then the scrub is started, scrub status tells me so, but nothing happens, no block in/out activity in vmstat, no =

CPU

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
related activity in top.
=20
btrfs scrub cancel then hangs, but not the complete mach=

ine,

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
only the process.
=20
I had this once on my T520 with the internal Intel SSD 3=

20 as

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
well. The other time it worked.
=20
Well maybe that is due to BTRFS doing something else on =

my T23

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
now:
=20
deepdance:~> ps aux | grep ino-cache | grep -v grep
root 1992 5.5 0.0 0 0 ? D 12:1=

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
0:09 [btrfs- ino-cache]
=20
[=E2=80=A6]
=20
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
At least it doesn=C2=B4t lock up hard, so there might re=

ally be

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
something strange with /.
=20
FWIW a btrfs filesystem balance / does work. After this a=

btrfs

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
scrub start / still locks the kernel.
=20
Hi Martin,
=20
I just sent 2 patches to the list. Could you please test if=

these

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
fix your problem with scrub?
=20
I didn=C2=B4t yet test it but I tried the first balance then =

scrub stuff

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
=20
Quoted 1 line
again:
Looks like you're on a 32 bit machine. The current for-linus b=

ranch

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
has an important fix for scrub on 32 bit that should solve this=

=2E

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
=20
So finally - the machine did make-kpkg over night and complained =

about

Quoted 1 line

Quoted 1 line
Quoted 1 line
missing Documentation lguest, then I switched off lots from distr=

Quoted 1 line

Quoted 1 line
Quoted 1 line
default config and just did the usual make stuff - I was able to =

scrub

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
both partitions on that ThinkPad T23:
=20
deepdance:~> btrfs scrub status /
scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275 =20
        scrub started at Fri Mar 16 11:56:12 2012 and finished af=

ter

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
=20
741 seconds total bytes scrubbed: 9.62GB with 0 errors =20
deepdance:~> btrfs scrub status /home
scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d =20
        scrub started at Fri Mar 16 12:00:31 2012 and finished af=

ter

Quoted 20 lines

Quoted 6 lines
Quoted 6 lines
=20
1708 seconds total bytes scrubbed: 36.63GB with 0 errors =20
Thanks a lot for fixing this.
=20
Tested-by Martin Steigerwald <[email protected]>
Quoted 14 lines
=20
[=E2=80=A6]
=20
Would that patch
=20
Btrfs: fix casting error in scrub reada code
=20
http://git.kernel.org/?p=3Dlinux/kernel/git/mason/linux-
btrfs.git;a=3Dcommit;h=3Da175423c831ea582c06784d1e172d2ce1d79923a =20
(sorry for line break. KMail insists on it even when I disable line breaks due to the minus sign in the URL.)
=20
that I tested above be something for stable?

Quoted 5 lines

=20
<formletter>
=20
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.tx=

Quoted 3 lines

for how to do this properly.
=20
</formletter>

What point of the rules do you refer to? Is it

- It or an equivalent fix must already exist in Linus' tree (upstream)=
=2E

Or do you want the patch quoted in the mail?

Anyways its not yet in linus tree AFAIR and from my side it was a quest= ion=20
whether it should be included at all. I thought it might be good ccing = you on=20
that question already.

Chris, how about this patch for stable once it hits Linus' tree?

Thanks,
--=20
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg Kroah-Hartman

2012-03-19 15:48 UTC #18 lore raw

Quoted 11 lines · Martin Steigerwald

Quoted 7 lines
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly.
</formletter>
What point of the rules do you refer to? Is it
- It or an equivalent fix must already exist in Linus' tree (upstream).

Yes.

Without that, there's nothing I can do with this.

Quoted 5 lines

Or do you want the patch quoted in the mail?
Anyways its not yet in linus tree AFAIR and from my side it was a question whether it should be included at all. I thought it might be good ccing you on that question already.

It's nice, yes, but note that you sent this to me directly, didn't cc:
the proper stable mailing list so that others who maintain other stable trees also didn't get the notice, and again, there's really nothing that the stable maintainers can do about this at the moment.

But, if this does go to Linus's tree, then [email protected] would be very interested in knowing about it.

thanks,

greg k-h

Martin Steigerwald

2012-03-19 16:03 UTC #19 lore raw

Am Montag, 19. M=E4rz 2012 schrieb Greg Kroah-Hartman:

Quoted 4 lines · Martin Steigerwald

Quoted 3 lines
Quoted 3 lines
<formletter>
=20
This is not the correct way to submit patches for inclusion in th=

Quoted 1 line

Quoted 1 line
Quoted 1 line
stable kernel tree. Please read Documentation/stable_kernel_rule=

s.txt

Quoted 7 lines

Quoted 7 lines
Quoted 3 lines
for how to do this properly.
=20
</formletter>
=20
What point of the rules do you refer to? Is it
=20
- It or an equivalent fix must already exist in Linus' tree (upstr=

eam).

Quoted 9 lines

=20
Yes.
=20
Without that, there's nothing I can do with this.
=20
Quoted 4 lines
Or do you want the patch quoted in the mail?
=20
Anyways its not yet in linus tree AFAIR and from my side it was a question whether it should be included at all. I thought it might b=

Quoted 3 lines

Quoted 1 line
good ccing you on that question already.
=20
It's nice, yes, but note that you sent this to me directly, didn't cc=

Quoted 1 line

the proper stable mailing list so that others who maintain other stab=

Quoted 1 line

trees also didn't get the notice, and again, there's really nothing t=

hat

Quoted 1 line

the stable maintainers can do about this at the moment.

I did, but got the address wrong, missed the vger in it.

Anyway, I try to follow-up on this, when its in Linus tree (via git wai= t and=20
notify for commit? - nah just kidding, but would be useful ;)

Arne Jansen

2012-01-24 09:28 UTC #20 lore raw

In reply to Martin Steigerwald

Quoted 3 lines · Martin Steigerwald

Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
When I do btrfs scrub start / the machine locks immediately up hard.

Can you please give me the output of sysrq-w when the machine is locked up?

Thanks,
Arne

Quoted 20 lines

Then usually on next boot it stops on space_cache enabled message, but not the one for /, but the one for /home which is mounted later.
When I then boot with 3.1 it works. BTRFS redos the space_cache then while the machine takes ages to boot - I mean ages - 10 minutes till KDM prompt is no problem there.
I thought I just mention it here.
Since I got no hints on what to do, I probably redo both filesystems on the machine. Should that not work out, I switch the box to Ext4.
btrfs filesystem scrub works on my ThinkPad T520 with 64-bit debian and Intel SSD 320 and one 2,5 inch external drive as well as a 3,5 inch external backup drive both via eSATA, so this seems to be no principal issue. It also works on a workstation at work which has 32-bit debian as well.
Thanks,

Martin Steigerwald

author

2012-01-24 10:16 UTC #21 lore raw

Am Dienstag, 24. Januar 2012 schrieb Arne Jansen:

Quoted 7 lines · Martin Steigerwald

Quoted 3 lines
Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
When I do btrfs scrub start / the machine locks immediately up hard.
Can you please give me the output of sysrq-w when the machine is locked up?

What would be the easiest way to do that?

The machine is locked up, means, no mouse, no keyboard, no ping - as far as I remember I tested a ping, but I can verify -, no nothing.

Serial console with USB serial adapter?

Thanks,

Signature · 2 lines

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Arne Jansen

2012-01-24 10:29 UTC #22 lore raw

Quoted 6 lines · Martin Steigerwald

Am Dienstag, 24. Januar 2012 schrieb Arne Jansen:
Quoted 5 lines · Martin Steigerwald
Quoted 3 lines
Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
When I do btrfs scrub start / the machine locks immediately up hard.

Quoted 7 lines

Quoted 2 lines
Can you please give me the output of sysrq-w when the machine is locked up?
What would be the easiest way to do that?
The machine is locked up, means, no mouse, no keyboard, no ping - as far as I remember I tested a ping, but I can verify -, no nothing.

Hm, I always use a (hardware) serial console, but I think on default loglevel the sysrq-output goes to dmesg only, so you have to adjust the loglevel also. Normally I have a ssh into the box running with a tail -f /var/log/messages. This locks up very seldom.
Have you tried some sysrq combinations? It might work, even when the keyboard looks locked up in all other respects.

Quoted 4 lines

Serial console with USB serial adapter?
Thanks,

Martin Steigerwald

author

2012-01-24 10:39 UTC #23 lore raw

Am Dienstag, 24. Januar 2012 schrieb Arne Jansen:

Quoted 7 lines · Martin Steigerwald

Quoted 6 lines
Am Dienstag, 24. Januar 2012 schrieb Arne Jansen:
Quoted 5 lines · Martin Steigerwald
Quoted 4 lines
Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
=20
When I do btrfs scrub start / the machine locks immediately up hard.

Quoted 7 lines

Quoted 7 lines
Quoted 3 lines
=20
Can you please give me the output of sysrq-w when the machine is locked up?
=20
What would be the easiest way to do that?
=20
The machine is locked up, means, no mouse, no keyboard, no ping - a=

Quoted 8 lines

Quoted 1 line
far as I remember I tested a ping, but I can verify -, no nothing.
=20
Hm, I always use a (hardware) serial console, but I think on default loglevel the sysrq-output goes to dmesg only, so you have to adjust the loglevel also. Normally I have a ssh into the box running with a tail -f /var/log/messages. This locks up very seldom. Have you tried some sysrq combinations? It might work, even when the keyboard looks locked up in all other respects.

Ok, so I may try the SSH way, maybe I get something before network gets= =20
nonfunctional. Or maybe I didn=B4t even test ssh/ping and network still= =20
works. But I think I tried accessing the machine via network, I usually=
do=20
this in such cases.

If that does not work and USB to serial adapter might work.

But then as far as I remember even audio locked up hard replaying the s= ame=20
sample all over again, so I do not know whether the kernel will do=20 anything at all.

Aside from that I got the idea to try to scrubbing with kernel 3.1 to=20 verify whether thats an regression.

Well I try some things and report back. Since the / filesystem on that=20 ThinkPad T23 is the only one it might have some wierd issues. Its one o= f=20
my oldest BTRFS filesystems.