From ed309ec2bf53fae26c7d2de6f5ab0d560556e575 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Lesimple?= Date: Mon, 8 Jul 2024 12:57:15 +0200 Subject: [PATCH] add some info about RS03 in readme --- README.md | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index cc31ce8..1583c15 100644 --- a/README.md +++ b/README.md @@ -50,31 +50,51 @@ The artefact is an **ecc** file, which must be stored on another media than the :two: **RS02** creates error correction data which is added to the medium to protect, we call this *augmenting* the image we're protecting. Damaged sectors in the error correction information reduce the data recovering capacity, but do not make recovery impossible - a second medium for keeping or protecting the error correction information is not required. +Intelligent adaptive reading is also available when reading a damaged RS02-protected disc: dvdisaster will only attempt +to read the minimum amount of required sectors to be able to rebuild the image, using a so-called "divide and conquer" +seeking mechanism, cutting off up to 90% of the time required to read and recover a damaged media. :three: **RS03** is a further development of RS01 and RS02. It can create both error correction files and augmented images, with the following added features: -- RS03 can use multiple CPU cores and is therefore **much** faster than RS01/RS02 on modern hardware. -- RS03 error correction files are - contrary to RS01, and to a lesser extent RS02 - robust against damage. -- RS03 is more robust, but also more restrictive: The augmented image must completely fill the medium now while the size of augmented images can be freely chosen in RS02. - The changes for parallel computation and higher robustness make RS03 a bit less space efficient, - e.g. RS03 error correction data has slighly less (around -3%) error correction capacity than its RS01/RS02 counterparts on images with equal size. +- It can use multiple CPU cores and is therefore **WAY** faster than RS01/RS02 on modern hardware. +- RS03 augmented images and error correction files are - contrary to RS01, and to a lesser extent RS02 - robust against + damage of the dvdisaster-added recovery data itself + +There are, however, a few cons that must be noted: + +- In image mode, the RS03 augmented image file size will be picked up from a predefined list of well-known medium sizes, + while the size of augmented images can be freely chosen in RS02. This is the "price to pay" for the added robustness + of the correction data. +- In image mode, intelligent adaptive reading is not available for RS03-protected images. The "divide and conquer" + algorithm will still be used, but dvdisaster will not stop as soon as enough sectors have been recovered to rebuild + the image: it'll attempt to read them all until you stop it, or until it tried to read all the sectors. You can still + stop it manually and attempt a "verify" of the resulting image file, to see if enough data has been read for recovery, + otherwise resuming the adaptive reading until this is the case. +- The changes for parallel computation and higher robustness make RS03 a tiny bit less space efficient, e.g. RS03 error + correction data has slighly less (around -3%) error correction capacity than its RS01/RS02 counterparts on images with + equal size. This is usually considered a cheap price to pay for the added robustness against corruption. Rough comparison table: -| Codecs | RS01 | RS02 | RS03 | -|------------------|--------------------------------|--------------------------------|--------------------------------| -| Robustness\* | :star: | :star::star::star: | :star::star::star::star::star: | -| Speed | :star::star: | :star: | :star::star::star::star::star: | -| Space efficiency | :star::star::star::star::star: | :star::star::star::star::star: | :star::star::star::star: | -| Augmented images | :x: | :heavy_check_mark: | :heavy_check_mark: | -| Separate files | :heavy_check_mark: | :x: | :heavy_check_mark: | +| Codecs | RS01 | RS02 | RS03 | +|-----------------------------------------------------|--------------------------------|--------------------------------|--------------------------------| +| Create ECC-augmented images | :x: | :heavy_check_mark: | :heavy_check_mark: | +| Create separate ECC files | :heavy_check_mark: | :x: | :heavy_check_mark: | +| Robustness :small_red_triangle_down: | :star: | :star::star::star: | :star::star::star::star::star: | +| Space efficiency | :star::star::star::star::star: | :star::star::star::star::star: | :star::star::star::star: | +| Computational generation speed :small_blue_diamond: | :star::star: | :star: | :star::star::star::star::star: | +| Computational repair speed :small_blue_diamond: | :star::star: | :star::star: | :star::star: | +| Damaged media recovery speed :white_square_button: | N/A :small_red_triangle: | :star::star::star: | :star: | +| Supports custom augmented image size | N/A :small_red_triangle: | :heavy_check_mark: | :x: | + +:small_red_triangle_down: Robustness against corruption of the dvdisaster-added ECC parts themselves. The higher the ranking, the less it is likely than a few badly located damaged sectors render the whole correction impossible because they affect dvdisaster metadata on-disc. For example corruption of the first dozens of sectors of an image can make RS02 entirely unusable regardless of the redundancy. -\*Robustness against corruption of the dvdisaster-added ECC parts themselves +:small_blue_diamond: When algorithm is CPU-bound, i.e. generating or repairing an image stored on a SSD/NVMe drive -A rough decision chart follows: +:white_square_button: Using adaptive reading, taking into account the time the drive takes to try to read damaged sectors -![dvdisaster codec decision chart](https://i.imgur.com/QTgiack.png) +:small_red_triangle: Only applicable for augmented images # :bulb: Rationale