On Fri, 2008-08-15 at 10:49 +0100, Daniel Berrange wrote:
On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote:
> [*] Well ... almost. Note that directory pools have a similar issue --
> the "source" of the pool is given by the <target> <path> --
there's no
> <source>. I suppose implementing directory pool discovery (for the sake
> of completeness) means addressing this as well, maybe via some similar
> mechanism ...
We already have a <source><directory>....</directory></source>
element
we use for NFS exports. I didn't bother with it for directory pools
because it'd be duplicating info from the target path, but in retrospect
we should use it for directory pools.
Sounds good. Perhaps (for back-compatibility) it should default to the
target path if not specified? (And maybe target path should default to
source directory if it's not specified??)
Perhaps we could even use it for the LVM pools instead of adding a
new
<name> element - eg,
<source><directory>/dev/VolGroup00</directory></source>
<source><directory>/dev/VolGroup01</directory></source>
I don't feel too strongly about this though - either name or directory
in the source would do the job for LVM pools nicely.
I don't think source directory makes sense for LVM. The LVM target path
is really a target-dependent convention controlled by the local LVM (or
udev) configuration. It's not specified anywhere in the LVM metadata on
disk (unlike VG name, which is specified). So I think we need to stick
with source name.
I'll fix the allocation issue Daniel V pointed out and resubmit shortly.
Then I'll work these decisions into the storage pool discovery patch and
resubmit that. And I'll submit another (small) patch to allow (and
properly default) source directory for directory pools.
Dave