On Tue, Oct 09, 2012 at 03:49:01PM +0200, Olivier Bonvalet wrote: > On 09/10/2012 14:32, David Sterba wrote: > >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 > > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y > CONFIG_CC_STACKPROTECTOR=y > # CONFIG_DEBUG_STACK_USAGE is not set > CONFIG_USER_STACKTRACE_SUPPORT=y > # CONFIG_DEBUG_STACKOVERFLOW is not set > > I suppose it's CONFIG_DEBUG_STACK_USAGE ?
I looked into the sources which config option enables the /proc/./stack output, but I don't know which one is it in the menuconfig. > Well... I don't know if it is related to that space cache, but the cleanup > process is now working : it makes a lot of write requests, and I have now > 30Go of free space. So it will be solved soon. Great, looks like it was able to do some progress and free more space for further work. > Any chance that it can be related to that space cache feature ? The problem is that if the space is tight, it slows down operations that depend on it. I've seen very slow snapshot cleaning in similar situation, free-space was constantly working. So it is related, but also expected and IMHO unavoidable. > >Probably no, although if you're fast enough and add another device before > >the cleaner starts, it could work :) > > Ho it's possible, it's a virtualized system, so the device can easily grow. That makes a difference of course :) > I was starting to patch my kernel before to see it's now solved. Glad to hear that, david -- 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
