On Tue, Oct 09, 2012 at 12:07:20PM +0200, Olivier Bonvalet wrote: > I didn't see any "stack" entry in /proc/$PID/ ; I will try to find which > kernel option export that.
CONFIG_STACKTRACE > >If the problem persists accross reboots, how long after mount does it > >take to get to this state? Cleaner usually kicks in after the 30 second > >transaction commit period, so this should be easy to verify if it's > >immediate or if it requires some load to get into the dead state. > > The cleaner process get it's state D between 30 and 60 seconds after the > reboot. But that cleaner process should not throw a lot of write access ? It needs to update the references so does both reads and writes. > This time I tried to remount with the space-cache enabled, there is a lot of > read access now. Does that space cache will help to find "free locations" ? Yes. As for the reads, the free space needs to fill the memory structures, if the disk is almost full there are also quite some data to read before it's complete. But reads are not the problem. > I suppose I can't resize the FS without solving that cleanup deadlock before > ? Probably no, although if you're fast enough and add another device before the cleaner starts, it could work :) Other than that, these are the patches that should fix the deadlock: https://patchwork.kernel.org/patch/1383951/ https://patchwork.kernel.org/patch/1383941/ (it touches vfs and needs recompiling whole kernel, not just btrfs) david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
