Re: Weird blocks at fsync() calls using md

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Neil Brown (neilb@xxxxxxx):

> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux