Re: Queuing of dm-raid1 resyncs to the same underlying block devices

[Neil Brown <neilb@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 903 bytes --]

Heinz Mauelshagen <heinzm@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]