Hello, On Mon, Mar 14, 2005 at 08:59:00PM +0100, Gorazd Golob wrote: > > > >I have no idea, and so I must guess. I guess that if you try the same > >application on a different computer it will work reasonably fast and > >that the problem is hardware doing extensive retries. > We have tests on ext3 and it wasn't like fast, but few minutes, not 30 > minutes.. > > > >Or, you are doing completely random IO with tiny little bits of dirty > >data in a large file, and so each 4k is a seek. I doubt this, but in > >theory.... > No.. there is really "random" data in this files, but files are small > (most of them less than 4 kb).
can you repeat the test with earlier kernel, like 2.6.9 + the patch from ftp.namesys.com ? just to be sure that the bug wasn't introduced recently. > >Or you have something else on that machine dirtying lots of memory after > >the application closes, and perhaps there is a flaw in our method for > >forcing atoms to disk after they get old that we should look into. > There were no other applications on that system and none of user land > deamons were using that partition. > > > >Finally, it could be none of the above and something is wrong in our > >sync algorithms, and somebody should log onto your machine and look at it. > Thanks. It is better to find how to reproduce the bug in our test environment (kGDB :-). > > > >Probably all guesses are wrong, but I have to ask them as a start. > Hope it helped.. if you have managed to create tons of independed atoms, tons of independed commits may take a lot of time :( > tnx, gorazd -- Alex.
