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
> > 13:28:13.006702 close(3) = 0
> Yes, it's weird. The sync of the .swp file takes a lot longer than
> the fsync of the actual file you are saving....
Yup. And it's always the fsync() on the .swp file too ;)
> I have this theory that there might be some odd interaction between md
> and the drive scheduler.
Well, i never really understood the big difference between the three
models. I used to do deadline on servers, but that turned out to be
REALLY bad (at least on our intranet server). Caused major load on
writes, made NFS b0rk, and when i switched it back to Anticipatory it
was all normal again, so that's what i used afterwards.
Using CFQ gives the same, maybe even worse results.
As does Deadline :S
Strange huh! Only this time the fsync() wasn't on the .swp file but on
the "real" file after writing it's contents...
Kind regards,
Sander.
--
| He broke into song because he couldn't find the key.
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
