Hi Jonathan,
> 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.
>
Probably isn't needed with section keywords. Something not "core" od
"disk"
is format2.
> 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.
>
>From the user side good since it allows more flexibility. The downside is
that
it adds complexity to the kernel parsing. And there might be sections that
depend on each other...
> 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
>
Or something like
devices 2 2 543:3 S 2 253:4 A
so each device can have a different number of arguments?
> 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. Multipath doesn't have that, and neither does mirroring
> when specifying the log device. For the above example, I did add an
>
Personally I think the offset is useful if doing mappings for complete
partitions/disks and the log should rather have it as well.
> 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.
>
I don't know if this can be solved in a nice way without completely
changing
the way the layout is today. :/ I undestand why going this way but it
feels
a bit ugly to have the same device specification twice. If there would be
something like
devices 2 2 253:3 rr_min=1000 3 253:4 mstate=m rr_min=1000
every per device option would be in one place. But parsing would have to
be
done more than once...
> 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.
>
It makes identification of section simpler to parse by the human reader
which
I like as well. ;-)
Stefan
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
