On Jan 4, 2013, at 10:16 PM, Piotr Szymaniak wrote: [snip] >> >> So, maybe the nature of /var/tmp/kdecache-$USER/foo.kcache is a reason >> of the issue. It is a very interesting detail. Could you share more >> details about this file? I mean size, creation time, modification >> time, owner, rights and so on. Moreover, could you share more details >> about your hardware environment? I mean CPU and RAM details. > > maszn ~ # file /var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache > gives me an i/o error and remounts ro. > > maszn ~ # stat /var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache > File: ‘/var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache’ > Size: 84213856 Blocks: 165144 IO Block: 4096 regular file > Device: 802h/2050d Inode: 102230 Links: 1 > Access: (0664/-rw-rw-r--) Uid: ( 1001/ appe) Gid: ( 414/ appe) > Access: 2012-11-14 16:15:01.377207479 +0100 > Modify: 2012-11-14 16:15:01.377207479 +0100 > Change: 2012-11-14 16:15:01.377207479 +0100 > > Intel Pentium Dual-Core E5400, 4GB RAM, nilfs2 is located on part of > Kingston SSD. It runs x86 Gentoo Linux with vanilla kernel (from > kernel.org) and I try to keep it up to date (3.6.8 right now, but I was > away for some time) and recent nilfs-utils from the portage tree (this > could also be considered as "up to date" or "up to upstream releases"). > Thank you for details. > >> I think that it can be very interesting to know about how this file is >> distributed on the volume. Could you get by means of dumpseg >> information about several last segments? I don't know how many it >> needs for understanding but maybe about 10 can be enough for the >> beginning. > > The file is pretty old so last 10 segments won't solve the issue, right? > You know that only patch can solve the issue. :-) I simply try to collect enough details about the issue for deep understanding of it. There are two ways of issue investigation: (1) reproducing on my side; (2) preparing special debug output that can give more details about the issue on your side. So, I feel necessity to prepare a patch with additional debug output that can be enabled in NILFS2 in the case of special needs. Currently, I have such understanding of the situation. As I can see from the error output and preliminary code analysis, it occurs situation when allocation code discovers that memory page is uptodate before reading. It can means that we have synchronization issue. But it needs to investigate situation more deeply. Now I am preparing patch for another issue with very long mount time. So, when I end this activity then I begin more deep investigation of the issue with readonly fs. Thanks, Vyacheslav Dubeyko. > Piotr Szymaniak. > -- > Natezyl sluch. Nic poza odglosami owadow z dziedzinca i naszeptywaniem > spryskiwaczy trawnika. Nic poza miarowym kapaniem z kranu w lazience. > To bylo niczym zycie, skapujace kropla po kropli. K a p, k a p, k a p, > wszystko w kanal. > -- Graham Masterton, "The Burning" -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
