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@xxxxxxxxxx
> 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@xxxxxxxxxx PHONE +49 171 7803392
FAX +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
