Hi again! Any hints about this one? Since scrubbing worked okay on other machines, I can also redo the BTRFS filesystem on this machine. Maybe it really has gained a corruption. (Still scrubbing should not lock up the kernel hard, but…) Thanks, Martin Am Samstag, 17. Dezember 2011 schrieb Martin Steigerwald: > Hi! > > 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, > no mouse and no ssh connection anymore: > > deepdance:~> btrfs scrub start / > scrub started on /, fsid […] (pid=5737) > deepdance:~> Write failed: Broken pipe > > > 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: > > 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 > 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 > [ 55.479303] Installing knfsd (copyright (C) 1996 okir@xxxxxxxxxxxx). > [ 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 > 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) (ch@xxxxxxxx) > (gcc 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´t 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 > as well again. Its again converting the old style inodes. Thus I think > 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. > > But then I had this after upgrading from 3.0 to 3.2-rc4 as well. I > didn´t report it here cause I thought it was a one-time issue. > > Hopefully you can make something out of the backtraces I tried to > snapshot 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 > 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. > > Thanks, -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
