<p><a href="https://github.com/cgwalters" class="user-mention">@cgwalters</a>: easy enough to wrap syncfs(2) into a measurement harness:</p>
<p><code>==> 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</code></p>
<p>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).</p>
<p>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 ...</p>
<p>(aside)<br>
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.</p>
<p>Finally the wall-clock time for kernel-core RPM install clocks in at</p>
<p><code>2.84user 1.04system 3:44.12elapsed 1%CPU (0avgtext+0avgdata 221228maxresident)k 200inputs+75808outputs (3major+92612minor)pagefaults 0swaps</code></p>
<p>So syncfs(2) is merely 45x slower than the BASE measurements I reported before.</p>
<p>I'll stick with fdatasync+fadvise+fsync (~30x slower) until I hear something better.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-295073080">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb801CGs-dXgISzHQgWkoDJ0KmPai0mks5rxYepgaJpZM4MyLOi">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb8051O-LvkNkwELmBok_0Y3N__NNEjks5rxYepgaJpZM4MyLOi.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-295073080"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #187: @cgwalters: easy enough to wrap syncfs(2) into a measurement harness:\r\n\r\n`\r\n==\u003e Fclose(0x614000008e40)      | LIBIO 0x612000004fc0(-1) fdno -1 | UFD 16 fp 0x612000004fc0\r\n--\u003e Fincore(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66\r\n\u003c-- Fincore(0x614000008e40) fdno 16 rc 919\r\n--\u003e Syncfs(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66\r\n\u003c-- Syncfs(0x614000008e40) fdno 16 rc 0\r\n--\u003e Fincore(0x614000008e40) fdno 16 path /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66\r\n\u003c-- Fincore(0x614000008e40) fdno 16 rc 919\r\n\u003c--     fdClose(0x614000008e40) rc 0    | UFD -1 fp 0x612000004fc0\r\n FDIO:      30    write(s),  3763601 total bytes in 0.003511 secs\r\n FDIO:      32   digest(s),  3763601 total bytes in 0.034357 secs\r\n FDIO:       1    alloc(s),  3763601 total bytes in 0.000040 secs\r\n FDIO:       1   syncfs(s),        0 total bytes in 0.166156 secs\r\n FDIO:       2   incore(s),  7528448 total bytes in 0.000425 secs\r\n\u003c--     fdClose(0x614000008e40) rc fffffffffffffffe     | LIBIO 0x612000004fc0(-1) fdno -1 | UFD -1 fp (nil)\r\nD: fini      100600  1 (   0,   0)     3763601 /opt/local/tmp/lib/modules/4.11.0-0.rc6.git2.1.fc27.x86_64/System.map;58f6dc66\r\n`\r\n\r\nFor 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).\r\n\r\nThen 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 ...\r\n\r\n(aside)\r\nAnd 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.\r\n\r\nFinally the wall-clock time for kernel-core RPM install clocks in at\r\n\r\n`2.84user 1.04system 3:44.12elapsed 1%CPU (0avgtext+0avgdata 221228maxresident)k\r\n200inputs+75808outputs (3major+92612minor)pagefaults 0swaps`\r\n\r\nSo syncfs(2) is merely 45x slower than the BASE measurements I reported before.\r\n\r\nI'll stick with fdatasync+fadvise+fsync (~30x slower) until I hear something better.\r\n\r\n\r\n\r\n"}],"action":{"name":"View Pull Request","url":"https://github.com/rpm-software-management/rpm/pull/187#issuecomment-295073080"}}}</script>