On Wed, 1 Oct 2014 13:57:24 -0500 Brassow Jonathan <jbrassow@xxxxxxxxxx> wrote: > > On Sep 30, 2014, at 9:56 PM, NeilBrown wrote: > > > So that is probably what I would do: > > - new version for bitmap which has 2 bits per region and encodes 3 states > > - bitmap granularity matches chunk size (by default) > > - decouple region size of bitmap from region size for internal 'dirty' > > accounting > > - write to a 'state 3' region sets it to 'state 2' and kicks off resync > > - 'discard' sets state to '3'. > > There are scenarios where we do not trust the bitmap and perform exhaustive searches (scrubbing). When we do this, we assume that the bitmap has been correctly handled, but the data has been corrupted somehow. When we scrub, we now could presumably use the bitmap to avoid those regions that have been discarded. However, are there problems to be considered when the corruption is the other way around - i.e. when the bitmap/superblock are corrupted instead of the data area? Do we consider problems like this unlikely because of the frequency of superblock writes? (The bitrot that I am familiar with usually happens in areas that are not touched very often - especially if they exist near areas that /are/ touched very often.) > > brassow Good question.... I suspect the frequent writes that you mention would reduce the chance of bitrot - and would make it quickly disappear if it did happen. Maybe we could compare bitmaps across all devices as the array is assembled and take some action if there are differences(??). NeilBrown
Attachment:
pgprza9jdWB7t.pgp
Description: OpenPGP digital signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
