[dm-devel] [RFC] Change to the mirror table map

[Heinz Mauelshagen]

On Thu, Oct 19, 2006 at 03:56:18PM -0500, Jonathan Brassow wrote:
> The impetus for this was the desire to add read balancing to mirroring
> and have it share code with multipath.

Makes sense.

> 
>  brassow
> 
> ORIGINAL:
> <start> <length> mirror \
> <log_type> <#log_params> <log_params> \
> <#mirrors> <device1> <offset1> ... <deviceN> <offsetN>
> 
> Example:
> 0 1024000 mirror \
> disk 3 253:2 1024 block_on_error \
> 2 253:3 0 253:4 0
> 
> 
> MODIFIED:
>                           [-------- logging section ---------] [- mirror devices section -] [--------------- read balancing section -------------]
> 0 71014400 mirror format2 log 4 disk 253:2 1024 block_on_error devices 2 1 253:3 S 253:4 A  read-balance 8 round-robin 0 2 1 253:3 1000 253:4 1000
> ^    ^       ^       ^     ^  ^  ^   <^^^^^^^^^^^^^^^^^^^^^^^>    ^    ^ ^   ^   ^              ^       ^ <^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
> |    |       |       |     |  |  |   |                            |    | |   |   |              |       | |
> |    |       |       |     |  |  |   |                            |    | |   |   |              |       | same as multipath
> |    |       |       |     |  |  |   |                            |    | |   |   |              |       # read-balance args
> |    |       |       |     |  |  |   |                            |    | |   |   |              read-balance section indicator
> |    |       |       |     |  |  |   |                            |    | |   |   Device status (slave/active/dead)
> |    |       |       |     |  |  |   |                            |    | |   Device
> |    |       |       |     |  |  |   |                            |    | # of device args
> |    |       |       |     |  |  |   |                            |    # of devices
> |    |       |       |     |  |  |   |                            device section indicator
> |    |       |       |     |  |  |   log type specific args
> |    |       |       |     |  |  log type
> |    |       |       |     |  # of log args
> |    |       |       |     log section indicator
> |    |       |       target table format
> |    |       target name
> |    target length in 512-byte blocks
> starting offset of target
> 
> New features:
> ================================================================================
> I've added a format argument ("format2" in example).  It is always the first
> argument to the mirror target.  If it isn't present, we can assume the original
> format.  If it is present, we can use the format specified.

Makes sense for backward compatibility and makes parsing easy.

> 
> The mapping table is broken up into sections.  The sections are allowed to be
> in any order, and we should be able to add sections in the future if
> necessary.
> 
> The logging section starts with the keyword 'log' and is followed by the number
> of log arguments.  No changes to the dm_create_dirty_log function should be
> necessary.

Again an advantage for parsing.

> 
> The devices section starts with the keyword 'devices' and is followed by the
> number of devices then the number of per device arguments.  This is not
> consistent with the other sections.  It may be better to have the keyword
> followed by the argument count, followed by the per device argument count.
> Something like:
>     devices 5 1 253:3 S 253:4 A
> or
>     devices 5 2 253:3 S 253:4 A
> depending on if you want to include the device in the per device argument
> count.  Notice that I have done away with the 'offset' parameter found in
> the original.

Keep it: we need it to easier support things like lvm pvmove and for metadata
at the beginning of the mapped devices.

> Multipath doesn't have that, and neither does mirroring
> when specifying the log device.  For the above example, I did add an
> additional per device parameter to specify the status of a device.  I was
> imagining a scenario where IBM's slave context might be specified, or
> a new mirror device is added to the set.  With the indicator, you could
> tell which devices were in-sync, and which ones needed recovery.
> (Perhaps that is better left to an additional section, since it is not
> yet known how this functionality would be added.)

Yes, we can have a device-properties or domething section after the devices
one once that hash been sorted.

> 
> The read balancing section starts with the keyword 'read-balance' and is
> followed by the number of read balancing arguments.  After that, it is
> just like multipathing.  If we were certain that the devices section did
> not need any device specific arguments, we could combine the devices section
> and the read-balance section.  (This could be the case if we decided to
> add a section for initial device status and didn't need the offset argument.)
> Mirror does need to keep it's own list of devices, however; and it might be
> nice to be able to parse that section separate - rather than parse the
> read-balancing section twice.
> 
> Multipath takes the approach of having positional arguments (e.g. the 'number
> of features' argument is in a known place).  If we took this approach, we
> could eliminate the keywords.  However, I think I prefer the ability to
> identify sections.

I agree. Much more flexible for enhancements and for the ease of parsing.

Heinz

> 
> 
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Storage Development                               56242 Marienrachdorf
                                                  Germany
Mauelshagen at RedHat.com                            PHONE +49  171 7803392
                                                  FAX   +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-