Le 13.11.2005 01:55, Artur Makówka a écrit : > Hans Reiser wrote: > >> John Gilmore wrote: >> [snip] >>> >>> Oh, BTW. "The slowdown" as I called it is still there. I guess I >>> spoke to soon. The specific symptom is that the effected process >>> locks for a time, usually just a second or two, but sometimes a >>> minute or two and and at least once for many many minutes. I think >>> that the crash (soft lockup) that I reported earlier is related as >>> well. And it sounds like the comment that rvalles had about lockups >>> with mmaped files, except that it doesn't lock up permanently. Just >>> for a second or three usually. >>> >>> >>> >> zam, please comment. >> > > one more thing im pretty sure of - the 2.6.13mm3 without any reiser4 > additional patches (just clean 2.6.13mm3 as it has reiser4 already > built) is working fine. > > i mean, im not sure if this bug still exists here, but im 100% sure i > can write vim files easy without any downtime, so this is big difference. > > so for everyone with this bug - try clean 2.6.13mm3 from kernel.org. It > worked for me. i will wait with this kernel for a patch to stable line. > > Also - i will test it a little more tomorrow to be sure that this > version is bug free. >
Hello, It seems that fsync could be really slow when there is a lot of activity on the FS. I've done the following test : - on a reiser4 FS, unpack a fresh kernel tarball and start a compilation - open a new terminal, wait 1 minute and start editing a file on the same FS with vi. - hit ":w" and wait... $ strace -T vi foo 2>strace_vi.log $ grep fsync strace_vi.log fsync(3) = 0 <30.923808> $ My computer is a desktop with an Athlon XP 1600 and 512 Mb RAM. Write cache is disabled on the disk (hdparm -W0 /dev/hda). ~~ laurent
