[Rpm-maint] [rpm-software-management/rpm] Adding an event loop in RPM to run asynchronous operations. (#258)

[Jeff Johnson]

The attached patch adds allocate/fadvise/fdatasync/fsync functions in rpmio with the calls on I/O intensive install code paths.

In addition, two flags have been added to Fopen(): 'S' to do fsync-on-close, and '?' to do per-fd debugging.

Simple benchmarks for a kernel package installation (rechecking PR #197 measurements)

without fsync-on-close:

$ 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.54system 0:07.45elapsed 83%CPU (0avgtext+0avgdata 29780maxresident)k
0inputs+303336outputs (14major+18667minor)pagefuls 0swaps

with fsync-on-close

$ sudo /usr/bin/time ./rpm -U --root=/var/tmp/xxx --nodeps --force kernel-3.10.0-514.26.2.el7.x86_64.rpm 
...
5.70user 0.87system 1:15.05elapsed 8%CPU (0avgtext+0avgdata 29772maxresident)k
8inputs+306472outputs (14major+19052minor)pagefuls 0swaps

So fsync-on-close is  ~10x slower on whatever disk I happen to be using on CentOS7.

The next step will be to use libeio to run fdatasync+fadvise+fsync+close asynchronously.

[rpm+fsync.patch.gz](https://github.com/rpm-software-management/rpm/files/1199322/rpm.fsync.patch.gz)




-- 
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-320161172
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170804/2a41ec2a/attachment-0001.html>