[dm-devel] [RFC] Change to the mirror table map
Jonathan E Brassow
jbrassow at redhat.com
Thu Oct 26 16:35:26 UTC 2006
I've been giving this more thought, and trying to code up a proof of
concept. It hasn't been going as well as I'd like, and I could use
some more input.
Coding up the constructor is pretty easy for virtually any scenario we
might imagine. The evolving ideas below make sense in that we can
simply pass on the sections to functions and don't have to rework the
interfaces for the log constructor or path selection constructor.
However, things start to break down when we look at the "status"
function. When we print the "STATUSTYPE_TABLE", it should produce
information in the same form as the mapping table. Currently, the log
and path selection modules print their own portions of that information
- into a string that is shared with the parent (mirror in this case).
That hurts our ability to specify the number of arguments for a
particular section, and destroys the ability to interleave sections
(e.g. 'devices 7 2 253:3 0 rr_min=1000 253:4 0 rr_min=1000')
We could remember the mapping table string and simply print that out -
bypassing the submodules. Or, we could alter the submodules in some
way. (Perhaps adding a function like "status_args" that would tell us
ahead of time how many arguments there are - allowing us to write "log
<#log_args>" before calling log_status.)
While we are thinking about this, I'd like to also include the
'features' idea into the mirror mapping table. For example: 'features
<#feature args> <features>', where <features> might be 'handle_errors'
and 'allow_io_delay 120'.
Right now, I'm leaning toward adding the additional function
"status_args" and adding the 'features' section as a new section.
Thoughts/advice are welcome,
brassow
On Oct 24, 2006, at 4:30 AM, Heinz Mauelshagen wrote:
> 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
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-
>
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
More information about the dm-devel
mailing list