pmatilai commented on this pull request.
> +int rc = 0, ec = 0;
+
+if (fd == NULL)
+ return -1;
+
+fd = fdLink(fd);
+for (FDSTACK_t fps = fd->fps; fps != NULL; fps = fps->prev) {
+ if (fps->fdno >= 0) {
+rc = fsync(fps->fdno);
+ if (ec == 0 &&
Good if doing in fsm.h ( I haven't looked).
Meanwhile a 50x slower installation is intolerable for a package manager even
if opt-in.
Nor can an application like RPM be expected to detect whether the underlying
filesystem is on SSD or USB or rotational disk and adapt accordingly: there
simply
@n3npq Uh, I am doing it in lib/fsm.h not in Fclose(), I dunno what you are
talking about.
Yes, the fsync() is super expensive on rotation media, as mentioned, don't use
it in those cases.
As I mentioned, I don't have good numbers on the positive effects, only that
our databases stall far
Do you have measurements of the effect of fsync()?
The last time sync/fdatasync were suggested for RPM that I am aware of was
~2011 in Mandriva. The issue comes up every few years this century ...
Here was the effect of adding fsync/fdatasync to RPM, measure on otherwise
identical system with
Note that there is potentially a huge impact on tools that assume that rpms can
only be singly signed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The rpmsign man page says:
"Both of the --addsign and --resign options generate and insert new signatures
for each package PACKAGE_FILE given, replacing any existing signatures. There
are two options for historical reasons, there is no difference in behavior
currently."
But:
* added docs
* stopped destroying the FDs on sync
* changed the name of the macro to be prefixed with an `_`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
jaymzh commented on this pull request.
> @@ -1116,6 +1116,28 @@ int Fseek(FD_t fd, off_t offset, int whence)
return rc;
}
+int Fsync(FD_t fd)
+{
+int rc = 0, ec = 0;
+
+if (fd == NULL)
+ return -1;
+
+fd = fdLink(fd);
+for (FDSTACK_t fps = fd->fps; fps != NULL; fps
As to the name, the implementation has significant implications, and so I think
the name should be kept as-is...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
jaymzh commented on this pull request.
> @@ -231,6 +232,9 @@ static int expandRegular(rpmfi fi, const char *dest,
> rpmpsm psm, int nodigest, i
exit:
if (wfd) {
int myerrno = errno;
+if (rpmExpandNumeric("%{force_fsync_on_close}")) {
`oneshot` is processed in
Discovered while investigating something else, filing instead of fixing to
avoid getting completely distracted from the original issue...
Originally broken in commit 7f47cbbd7d1600ae280e48a655c9e870cf9361e0, partially
resurrected in commit ead9cdd587bbf052722f0f8598e0983e565e3415 but now only
pmatilai commented on this pull request.
> @@ -1116,6 +1116,28 @@ int Fseek(FD_t fd, off_t offset, int whence)
return rc;
}
+int Fsync(FD_t fd)
+{
+int rc = 0, ec = 0;
+
+if (fd == NULL)
+ return -1;
+
+fd = fdLink(fd);
+for (FDSTACK_t fps = fd->fps; fps != NULL;
pmatilai commented on this pull request.
> @@ -231,6 +232,9 @@ static int expandRegular(rpmfi fi, const char *dest,
> rpmpsm psm, int nodigest, i
exit:
if (wfd) {
int myerrno = errno;
+if (rpmExpandNumeric("%{force_fsync_on_close}")) {
You don't really want to invoke the
Actually I'm more on the side of questioning the need for a command line switch
in the first place. This is a highly special tweak that you'd permanently
enable and forget on those systems benefitting from it AIUI, and not something
you enable for every third transaction on the system.
--
You
Closed #186.
--
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/186#event-1027887725___
Rpm-maint mailing list
Ah yes, good call @Conan-Kudo - will add that tomorrow.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Like I noted in my first comment, the --target in rpmbuild is different (it
takes a comma-separated list) and can't be replaced this way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
My knowledge of Mono is about the same for now... But I'm willing to learn more
and work on it ; the script doesn't seem to be too complex and getting the
correct dependencies look like a matter of parsing some XML
--
You are receiving this because you are subscribed to this thread.
Reply to
Merged, thanks for the patch!
--
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/178#issuecomment-291406650___
Rpm-maint mailing
Merged #178.
--
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/178#event-1027819924___
Rpm-maint mailing list
The Mono dependency extraction scripts were contributed by an "outsider" about
ten years ago and have been untouched ever since, so it's not exactly a big
wonder that world around them has moved on a bit.
My knowledge about Mono ends shortly after the "it exists" level, so this would
be a case
spec.parsed is a nice little addition, I'll be happy to merge, but please drop
the cosmetics part.
I'm not at all fond of trailing whitespace fixes in general, but if you really
really want to do it, do it as a separate pull request and for the entire
python directory at once to minimize
22 matches
Mail list logo
