Some minor tinkering on the fdatasync -> fsync pipeline with code like this:
```
        pthread_yield();
        if (eio_npending()) rc = eio_poll();
```
to minimize the number of calls to eio_poll() (which always processes at least 
one request) gives these timings

```
$ sudo /usr/bin/time ./rpm -U --root=/var/tmp/xxx --nodeps --force 
kernel-3.10.0-514.26.2.el7.x86_64.rpm
...
5.67user 0.74system 0:17.65elapsed 36%CPU (0avgtext+0avgdata 29880maxresident)k
0inputs+300120outputs (0major+19150minor)pagefuls 0swaps
```

So using an event loop for asynchronous fsync-on-close is ~2.5x slower than not 
doing fsync, and has the added benefit)s) of filesystem durability and no I/O 
cache blowout on large upgrades.

That is a quite acceptable overhead for always doing fsync-on-close IMHO: YMMV 
as always.

Note that no scripts are running in my silly 1 kernel upgrade testing: 
overlapping fsync-on-close with scriptlet execution may result in further 
improvements in The Real World.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/258#issuecomment-320493837
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to