Comments on: DRBD 8.2.0 introduces protocol integrity checksums http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/ Linux, DRBD, and other stuff of interest Sun, 15 Nov 2009 11:29:27 +0000 http://wordpress.com/ hourly 1 By: Florian Haas http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-841 Florian Haas Tue, 02 Oct 2007 12:16:08 +0000 http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-841 Alexander, from our perspective there are no arguments against using 8.2.0 in production. The two branches will continue to coexist for some time, with fixes from one branch being pushed to the other. Alexander, from our perspective there are no arguments against using 8.2.0 in production. The two branches will continue to coexist for some time, with fixes from one branch being pushed to the other.

]]> By: Alexander Rubin http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-839 Alexander Rubin Tue, 02 Oct 2007 11:12:19 +0000 http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-839 Thanks, Florian. Version 8.2.0 - is it stable enough to run in production with disabled checksumming? Or - do you recommend downgrade it to 8.1.0 or 8.0.latest after the test (after we made sure that everything is fine with the data consistency)? Thanks, Florian.

Version 8.2.0 – is it stable enough to run in production with disabled checksumming? Or – do you recommend downgrade it to 8.1.0 or 8.0.latest after the test (after we made sure that everything is fine with the data consistency)?

]]> By: Florian Haas http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-833 Florian Haas Tue, 02 Oct 2007 07:41:52 +0000 http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-833 Alexander, #1, due to added CPU utilization/computational overhead. #2, CRC-32C will most likely generate less overhead than MD5. However, MD5 is the stronger hash of the two and strictly speaking, provides a more reliable validation of replicated data. Up to you to define your priorities. #3, while increasing al-extents will improve your write performance due to a reduction in metadata operations on the Primary (for the price of having a longer resync time upon a Primary crash), this is unrelated to checksumming. Alexander,

#1, due to added CPU utilization/computational overhead.

#2, CRC-32C will most likely generate less overhead than MD5. However, MD5 is the stronger hash of the two and strictly speaking, provides a more reliable validation of replicated data. Up to you to define your priorities.

#3, while increasing al-extents will improve your write performance due to a reduction in metadata operations on the Primary (for the price of having a longer resync time upon a Primary crash), this is unrelated to checksumming.

]]> By: Alexander Rubin http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-830 Alexander Rubin Tue, 02 Oct 2007 02:25:37 +0000 http://fghaas.wordpress.com/2007/09/28/drbd-820-introduces-protocol-integrity-checksums/#comment-830 Do you recommend to disable checksumming in production due to added CPU utilization or due to that it is new/untested feature? Do you think MD5 or CRC-32C will better from the performance point of view? Do you recommend increasing al-extends to help with performance of checksumming? Do you recommend to disable checksumming in production due to added CPU utilization or due to that it is new/untested feature?
Do you think MD5 or CRC-32C will better from the performance point of view?
Do you recommend increasing al-extends to help with performance of checksumming?

]]>