Hi Piotr, On Mar 28, 2013, at 3:07 PM, Piotr Szymaniak wrote:
> On Thu, Nov 29, 2012 at 11:00:59AM +0400, Vyacheslav Dubeyko wrote: >> Thank you. > > Got this issue again (sincerely, I'm a bit lost and don't remember if > there was a patch for this?) > > >> I think that it needs to use such tools for the issue investigation: >> 1. echo t > /proc/sysrq-trigger should tell us what the flusher is >> doing. > > Attached. > Thank you for additional details. Unfortunately, your sysrq-trigger output is not complete. So, I can't make conclusion about what operation was a reason of issue on your side. Could you send to me the full log of sysrq-trigger output? I can easily reproduce the issue by big file (100 - 500 GB) deletion or truncation. Please, find description in: http://www.mail-archive.com/[email protected]/msg01504.html. This issue doesn't fixed yet. The issue has complex nature. I described the reason of the issue in e-mail: http://www.mail-archive.com/[email protected]/msg01547.html. I think that the issue requires long-term implementation efforts. First of all, it makes sense to implement extents support. If it doesn't resolve the issue completely then it needs to implement special technique of file deletion/truncation or to modify technique working with checkpoints. Currently, I don't start this implementation because of investigation of the issue with "bad b-tree node" issue. I have reproduction path for the issue (http://www.mail-archive.com/[email protected]/msg01558.html) and I am trying to localize the reason of the issue. But I worry that I can reproduce this issue for 1 KB block size. So, it can be a 1 KB block size related issue. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
