As promised, here is a proof-of-concept patch to permit using either
fwrite+fsync or mmap+madvise+msync while writing files onto the file system
from a *.rpm package.
The patch passes "make check" (with the current known failures) on tip.
There are various switches to enable/disable the added
I knew if I wrote a patch, better answers would instantly appear.
There is fadvise(FADV_DONTNEED) wrto fsync(2) analogous to
madvise(MADV_DONTNEED) wrto msync(2). I will add to my patch in the next few
days for measurement, todo++.
The easy answer for your "Chef installs packages and my
kaniini approved this pull request.
--
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/192#pullrequestreview-31695034___
It would be nice to solve this on freedesktop's implementation too, but their
resolver does not track depth, so the approach used here will not work there
without serious reworking :(
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
In case that binary compiled from source generated in /tmp, a
/usr/src/debug/tmp directory will be created with the same mode as
/tmp, a.k.a 777, which should be avoided.
Fixes: rhbz#641022
You can view, comment on, or merge this pull request online at:
ignatenkobrain approved this pull request.
--
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/194#pullrequestreview-31702779___
This trivial patch helps diagnose rpm behavior while developing or testing.
`
diff --git a/rpmqv.c b/rpmqv.c
index 8655776..4f448c2 100644
--- a/rpmqv.c
+++ b/rpmqv.c
@@ -354,5 +354,7 @@ int main(int argc, char *argv[])
rpmcliFini(optCon);
+rpmlog(RPMLOG_DEBUG, "exit code: %d\n",
Resolving file "colors" affects more than MIPS64 n32: the x32 format also uses
(1 <<2) color bit and (potentially) needs RPM to choose between executables
that are compiled differently.
AFAIK, PLD has succeeded in adding support for x32 to RPM5, if you need patches
that have been tested in
Thanks for measurements! Could you also attempt to measure the effect on RPM
too? Wall clock time is sufficient, as the time necessary to perform an upgrade
is what most RPM users are sensitive to.
Your graphs (presumably on SSD?) show smaller/periodic writes w fsync enabled,
and larger/delayed
