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

Jeff Johnson notifications at github.com
Wed Apr 5 08:45:37 UTC 2017


There is a modestly obscure means to attach *_DONTNEED (to achieve kernel delayed writes and removing pages when I/O is complete) using the existing rpm.org rpmfiArchiveReadToFilePsm() Fwrite->write(3) loop calling setvbuf(3) immediately after Fopen on the fopencookie(3) FILE *.

(aside)
Personally, I think mmap(2) and madvise(2) are easier to implement/maintain than rpmio fopencookie(3) wrapped stdio(3) abstractions like setvbuf(3): YMMV.

The idea behind *_DONTNEED -- to minimize competition for scarce resources -- is to hint to the kernel that RPM write buffers (actually pages) can be reused by other processes as soon as written to disk, rather than cached. RPM package installation is always fire-and-forget for package files, not true in general for file writes.

Letting the kernel manage its own resources as necessary may be sufficient to prevent database stalling/starvation as an alternative to attempting explicit fsync(3) invalidation of cached I/O buffers
which has the unfortunate side effect of blocking RPM until the fsync(3) system call returns.

(aside)
This *IS* what used to be in RPM, and was a significant win at the time (but also included directly uncompressing into the mmap(2) buffer avoiding a copy, and increasing the zlib buffer size from 32K -> 256K, which has long since been upstreamed). Someone else will have to speak to why mmap(2) was ripped out at rpm.org.

(hth, off to bed)

-- 
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/pull/187#issuecomment-291795090
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170405/4022b62c/attachment.html>


More information about the Rpm-maint mailing list