Re: Thinking aloud.

Hi.

On 10/23/2012 07:05 PM, Martin Fahr wrote:
> Hi Nigel,
>
> as for the checksums, I wouldn't even bother checksumming the whole 
> page. Checksumming only every 100th byte within the page might be 
> sufficient to give you a good idea whether the page is likely to have 
> changed or not. Obviously, this would not speed up a 
> memory-bandwidth-limited checksum, but saves some CPU cycles and energy.
Will your data be safe if the checksumming decides the pages are the 
same when they're not (because the 100th bytes matched but ones in 
between didn't) and the changed page isn't written to disk as a result? 
It's better to checksum the whole page.
> Do you have an idea of how many pages "typically" don't get touched in 
> between two hibernation cycles? I am aware that there's no such thing 
> as typical system or a typical hibernation cycle, yet I suspect it 
> would be good to know very roughly how much improvement could be 
> expected.
I don't, but that's part of what I'm hoping to find out.

I've started on it today, and so far have a new module that's 
calculating the SHA1 for every page that's written to disk. At the 
moment that's all it's doing, but it already gives useful info:

Booting to init S, my SSD writes a small image at approx 1300MB/s 
without the module enabled and 380MB/s with it. If that's at all 
representative of a 'real' image, we're going to want to see a 
significant portion of the image being the same if speed is going to be 
comparable. Then again, if you're writing a smaller image and getting 
less wear and tear on your drive, perhaps the tradeoff will be worth it.

Next step is to implement recording the checksums and then comparing 
them. That will take longer to do - I know how I'm going to do it, but I 
have other tasks to get on with first.
> If you didn't plan to do so already, it might be worthwhile to run a 
> simple test on a few systems to find out more. Maybe comparing the 
> uncompressed, unencrypted images from two subsequent hibernation 
> cycles (written to two separate files or partitions on the disk) would 
> do the job?
Perhaps, but I think just getting on with heading toward implementing 
and seeing what the numbers reveal as we go could be a better way - at 
least that way no effort is wasted if it does prove to be worthwhile.
> Finally, your work has always been very much appreciated by me. I have 
> to agree with Pedro very much though. Mainline integration of TOI 
> seems to be the most important missing feature and would allow a few 
> million more users to appreciate your work.
Thanks :)