Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald: > Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald: > > 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. > > > > 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 now tested scrubbing /home which is a different BTRFS filesystem on > 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 the > process. > > I had this once on my T520 with the internal Intel SSD 320 as well. The > 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 > /home. > > At least it doesn´t lock up hard, so there might really be something > strange with /. FWIW a btrfs filesystem balance / does work. After this a btrfs scrub start / still locks the kernel. Anyway, I might be waiting for the new fsck and try it on the partition. Or redo the filesystem from scratch, cause I think trying to debug this will take way more time. I might also as well redo /home as well. Two fresh 3.2 or 3.3 kernel BTRFS and see whether they work better. -- 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
