| Summary: | RFE optimize write updates | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> |
| Component: | rpm | Assignee: | Fedora Packaging Toolset Team <packaging-team> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aros, dmach, ffesti, jpokorny, pmatilai, rvokal |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-22 11:56:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Zdenek Kabelac
2012-01-20 15:19:02 UTC
Something like this has been suggested before... Avoiding writes on unchanged files would require rpm to calculate the digests (sha256 in fedora, not md5 btw) of all already installed files (often involving prelink undo) to see whether they should be replaced or not. This would generate an enormous amount of read io where none is currently needed. It might be beneficial for systems where writes are very expensive though. Read ops are pretty cheap on SSD - thus I wouldn't see it as a problem
and prefer this instead of pointless rewrites of SSD blocks with same data
(since number of block rewrites have there limits).
Also - aren't there already some hash sums stored with each file from package
(at least I've though that's what rpm -Va is doing - it compares all
files whether its sum is matching ('sha256').
BTW - on my system with 2433 packages with 4 year old Lenovo T61 (2.2GHz, 4GB) with some debug kernel options enabled.
time rpm -Va
real 5m0.893s
user 2m8.382s
sys 1m27.364s
While today's rawhide upgrade on my machine with 1628 files took this:
(Upgrade 1628, Remove 2, Skip (deps) 25, Download 1.3GB)
(BTW would be probably nice, if yum would remove installed file
immediately after successful installation, not after whole upgrade is
completed, since 1.3G takes quite lot RAM when downloaded to ramdisk)
takes already over an hour and still unfinished...
And also I'm wiling to take a risk of using just DB stored sums
thus not doing a life system check of all stored files.
Since for most packages I don't really care that much - maybe
I'd like to be able to select list of 'core' package, where I'd like
to have hash check - and for the rest use DB stored sums.
Relying on the stored digests is not an option. If you dont see why then think some more. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. *** Bug 530284 has been marked as a duplicate of this bug. *** Yeah, a duplicate a 4 years old feature request, why not vice versa? (Artem, I pretty much prefer temporal ordering preserved as well, but sadly people occasionally, sometimes accidentally don't share this view, we have to deal with it). Thanks for making this idea happen (suggestion originators and Pavlína): https://github.com/rpm-software-management/rpm/commit/29c48e14de414ca512e404a2d773c3fcb3578040 In the Fedora context, will there be any further integration, e.g. distro-driven switch of "_minimize_writes" macro where suitable (per SSD drive detection)? So, this is now in rawhide/F27 as of rpm >= 4.13.90. Autodetection is a would-be-nice some day in the future, but not going to happen in 4.14. CC'ing Daniel Mach 'cause it looks like he's into it. And why was this bug closed again? |