@cgwalters when moving 100's of megabytes through a finite resource, there will
be a measurable effect on the cache. that's true for any large I/O operation
including rpm-ostree: have you run mincore to see how many pages are left in
cache after syncfs? typically syncfs/sync guarantee write to disk, not removal
from cache.
Meanwhile there are not non-blocking variants of fsync/fdatasync (which is
essentially what an event loop provides, threads that can block, there are lots
of ways to block without stopping an application), nor are there notification
interfaces for any of these system calls.
Eliminating buffer bloat or adding priorities may improve performance, but will
not solve the core issues, that filesystem durability/determinism increases
reliability, and that 100's of Mb of I/O has an effect on system performance,.
The percentage of files that are generated by scripts in caches is vanishingly
small when compared to static content imho. Wanna bet? ;-)
--
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-320761934___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
