Thinking aloud.
Nigel Cunningham <[email protected]> Sat, 20 Oct 2012 08:20:28 +1100
| Newsgroups | gmane.linux.swsusp.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi all. For a few years now, TuxOnIce has been in maintenance mode, having reached a point where most of us seem to be pretty happy with the functionality it provides. Recently, however, I've started to think about one more way in which it could be improved. I'm not saying I'm going to start work on implementing this immediately (and maybe not ever), but I thought it might be good to share the idea with you and get it publicly documented that the idea was around before the implementation, lest fun things like patents come into the picture later (may it never happen!). Anyway, what I've been thinking about is that fact that each time we write the image, we write the complete image. Surely there must be a portion of the data that is exactly the same as last time, and therefore shouldn't need to be written again. If we could avoid writing that portion again, we would definitely reduce wear and tear on the drive(s) being written to, and potentially make writing the image [much?] faster. Hopefully this could be done without greatly increasing TuxOnIce's memory usage or the time taken to read the image. My initial thought is to use SHA1 checksums to determine what pages have changed, keeping those checksums (and the pfns to which they refer) in memory or on disk between hibernation cycles. This would also of course require us to not free storage between cycles, like with the Keep Image mode. (Is checksumming a full page and then compressing the data and writing it if necessary significantly faster (or slower?) than compressing a full page and then checksumming the compressed data?) A simple initial implementation could be to add the changed pages in each pageset to the end of the image, modifying the header so it knows of the existence of the extra data and loads it after loading the original image data (etc). The whole image could be rewritten when we run out of room for the incremental modifications, or after a fixed number of cycles, or triggered manually. We could also look at overwriting data in the image as contents change. It would probably reduce fragmentation if pages were sorted according to the number of times they'd changed (put pages that have never changed together since they're probably less likely to change in the future and so on). This would of course only make sense after you've already done some cycles. What do you think? Regards, Nigel