On Sat, 9 Sep 2000, Jens Axboe wrote:
On Sat, Sep 09 2000, Ravi K. Swamy wrote:
Well, yes and no. If you have enough memory to hold it all in cache, then there's no point in starting a flush early. However, if the cp as stalled we are indeed not flushing when we should. I'll try and reproduce it here.
I have 512MB of RAM. When I do things like untar a 20MB kernel src tree it does untar really quickly but then within a minute I hear the 10-20 seconds of syncing to the hard disk.
Right and that didn't happen. If cp doesn't return, it is an entirely different problem. I'm banging my head against fs/buffer.c atm looking at this.
Well hopefully I will soon have two machines to test this on so if you can suggest other types of testcases just let me know.
Sorry about that...
Is this version of ksymoops okay?
[snip]
Trace; c024b865 <__mon_yday+4385/5fa0>
Looks a bit weird, where the heck is this coming from?
I did compile another kernel afterward but i had saved the System.map from the kernel that was running when the bug happened. Then I rebooted to that kernel when I ran ksymoops. What's the weird part? I'm not a kernel expert... Is the trace the list of functions that have been called? and __mon_yday isn't a function but a data structure? I do see it used fs/udf/udftime.c