[dm-devel] Queuing of dm-raid1 resyncs to the same underlying block devices

[Neil Brown]

Heinz Mauelshagen <heinzm at redhat.com> writes:
>
> E.g. keep track of the 'new' state of the array and initialize
> parity/syndrome on first access to any given stripe with
> the given performance optimization thereafter.
>
> Metadata kept to housekeep this  could be organized in a b-tree
> (e.g. via dm-persistent-data), thus storing just one node
> defining the whole array as 'new' and splitting the tree up
> as we go and have a size threshold to not allow to grow
> such metadata too big.
>

This idea has come up before.  A bitmap has been suggested.  Simpler
than a B-tree, though not as flexible.
It would allows us to do something more meaningful with Discard: record
that the whole region is invalid.

I don't object to the idea, but I find it hard to get excited about.  It
further blurs the line between the filesystem and the storage device,
and duplicates work between the two.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20151009/44fbfb87/attachment.sig>