[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Hi Jonathan,

> New features:
> I've added a format argument ("format2" in example).  It is always the 
> 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 
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 
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 
> 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 
> followed by the argument count, followed by the per device argument 
> 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 
> count.  Notice that I have done away with the 'offset' parameter found 
> 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 
> 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 
> Mirror does need to keep it's own list of devices, however; and it might 
> 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 
the way the layout is today. :/ I undestand why going this way but it 
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 
done more than once...

> Multipath takes the approach of having positional arguments (e.g. the 
> of features' argument is in a known place).  If we took this approach, 
> 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 
I like as well. ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]