[Rpm-maint] [rpm-software-management/rpm] Add macro to force fsync() on close() (#187)

Jeff Johnson notifications at github.com
Wed Apr 19 04:03:53 UTC 2017

@cgwalters: easy enough to wrap syncfs(2) into a measurement harness:

==> Fclose(0x614000008e40)      | LIBIO 0x612000004fc0(-1) fdno -1 | UFD 16 fp 0x612000004fc0
--> Fincore(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66
<-- Fincore(0x614000008e40) fdno 16 rc 919
--> Syncfs(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66
<-- Syncfs(0x614000008e40) fdno 16 rc 0
--> Fincore(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66
<-- Fincore(0x614000008e40) fdno 16 rc 919
<--     fdClose(0x614000008e40) rc 0    | UFD -1 fp 0x612000004fc0
 FDIO:      30    write(s),  3763601 total bytes in 0.003511 secs
 FDIO:      32   digest(s),  3763601 total bytes in 0.034357 secs
 FDIO:       1    alloc(s),  3763601 total bytes in 0.000040 secs
 FDIO:       1   syncfs(s),        0 total bytes in 0.166156 secs
 FDIO:       2   incore(s),  7528448 total bytes in 0.000425 secs
<--     fdClose(0x614000008e40) rc fffffffffffffffe     | LIBIO 0x612000004fc0(-1) fdno -1 | UFD -1 fp (nil)
D: fini      100600  1 (   0,   0)     3763601 /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66

For starters, Fincore (which sums the pages reported by mincore(2) on the mmap'd fdno) indicates that no pages are removed from the system cache by syncfs(2) whatsoever. Likely fdatasync+fadvise are still needed with syncfs(2), just like with fsync(2).

Then syncfs(2) is clocking in at ~165 millisecs, which is ~3x worse than fdatasync+fadvise+fsync ~50 millisecs. Which is hardly surprising: the ext4 partition being sync'd is ~500Gb, much larger than the ~4Mb file I am measuring. Hard to compare coconuts with bananas ...

And sure os-tree can create/use smaller partitions to limit the amount of I/O necessary to sync to disk. RPM hasn't that luxury, and adding an artificial partition around an I/O benchmark is ... well ... rather a cheat. YMMV.

Finally the wall-clock time for kernel-core RPM install clocks in at

`2.84user 1.04system 3:44.12elapsed 1%CPU (0avgtext+0avgdata 221228maxresident)k
200inputs+75808outputs (3major+92612minor)pagefaults 0swaps`

So syncfs(2) is merely 45x slower than the BASE measurements I reported before.

I'll stick with fdatasync+fadvise+fsync (~30x slower) until I hear something better.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170418/57b7ec43/attachment-0001.html>

More information about the Rpm-maint mailing list