Sorry, but I didn't save top output this time.. But for sure, it was "mount /dev/md0 /nfs/raid -o ...." process. The CPU load was fully in kernel space. So while the mount call, the kernel was doing something very both IO and CPU intensive for almost 50 minutes. As I have already written the load was about 80MB/s read IO according to iotop, and about 60% of the first CPU core according to top. If this info is not sufficient I'll try to reproduce the case as soon as possible. -------------------------------------------------- Александров Сергей Васильевич 2012/11/16 Vyacheslav Dubeyko <slava@xxxxxxxxxxx>: > On Thu, 2012-11-15 at 16:08 +0300, Сергей Александров wrote: >> lssu, lscp after mount. Actually I missed the moment and >> nilfs_cleanerd has cleaned some data. >> Mount took about 50 minutes. >> > > Thank you for info. > > I have some additional questions after thinking about issue. As I > remember, you wrote that you tried to understand what process eats CPU > time during issue. But you don't share details about it. Could you share > details of "top" and "ps ax" outputs for the case of issue reproducing? > > With the best regards, > Vyacheslav Dubeyko. > >> -------------------------------------------------- >> Александров Сергей Васильевич >> >> >> 2012/11/15 Сергей Александров <splavgm@xxxxxxxxx>: >> > 2012/11/15 Vyacheslav Dubeyko <slava@xxxxxxxxxxx>: >> > >> >>> The bug appeared again. And apparently it's a kernel one. >> >>> My bad that I didn't notice that the CPU activity wals in kernel space. >> >>> The mount process hangs inside mount call itself. I've an strace >> >>> output, but it's not informative, it perfectly normal besides the hang >> >>> in mount call. >> >> >> >> I will try to reproduce the issue. As I remember, you described your >> >> environment with details. But what size of files you have preferably on >> >> your partition? Moreover, could you share strace output anyway? Because >> >> it can be a basis for understanding of achieving the issue reproducing >> >> and analysis of execution environment. >> > >> > Essentially there are three kind of files: large ones about 700MB-2GB, >> > video, written by rtorrent/libtorrent (with no preallocation, if it >> > matters)and physics numerical simulation files - about 2GB data files >> > and few killobytes long description files. >> > >> >> >> >> If you want to try to investigate and fix the issue by yourself then >> >> your strace output is needed also. >> >> >> >> By the way, could you share your dmesg output for analysis? >> > >> > strace and dmesg output attached. Mount is in progress. >> > >> >> >> >> I think also it can be very useful lscp and lssu output before sudden >> >> power off and after mount is ended successfully. Could you share it? >> > >> > It will be a bit hard to get the before data, but when mount will be >> > finished I'll send you after results. >> > >> > >> > I'll try to reproduce and get the before results too, but I am not >> > sure about it. >> > >> > >> > Best regards, >> > Aleksandrov Sergey Vasil'evich > > -- 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
