Quoting Neil Brown ([EMAIL PROTECTED]):
> > 13:28:07.011717 fsync(4)= 0
> > 13:28:12.748252 open("js_gen.pl", O_WRONLY|O_CREAT|O_TRUNC, 0770) = 3
> > 13:28:12.748427 write(3, "#!/usr/bin/perl -w\nuse strict;\nu"..., 2189) =
> > 2189
> > 13:28:12.748506 fsync(3)= 0
On Friday July 28, [EMAIL PROTECTED] wrote:
> Quoting Neil Brown ([EMAIL PROTECTED]):
>
> > Precisely what evidence do you have?
>
> I had a nicer strace. With the 30 seconds fsync() call in it. This one
> only took 4 seconds, but that's because only two of us were trying to
> generate enough dis
Quoting Neil Brown ([EMAIL PROTECTED]):
> Precisely what evidence do you have?
I had a nicer strace. With the 30 seconds fsync() call in it. This one
only took 4 seconds, but that's because only two of us were trying to
generate enough disk IO to make it happen ;)
Look here, the read(0, "\r", 25
On Friday July 28, [EMAIL PROTECTED] wrote:
> Hello list,
>
> I've recently subscribed to this list as i'm facing a little problem
> using md v0.90.3 (bitmap v4.39) on Linux 2.6.17.1, Debian 'sid', mdadm
> 2.4.1...
sounds fairly up-to-date.
>
> While the system is under heavy disk IO, calls to
Hello list,
I've recently subscribed to this list as i'm facing a little problem
using md v0.90.3 (bitmap v4.39) on Linux 2.6.17.1, Debian 'sid', mdadm
2.4.1...
While the system is under heavy disk IO, calls to fsync() made by vim
(for example) block for a LONG time. Like 30 seconds or more. I'm
