On 08/02/2011 07:11 PM, Daniel P. Berrange wrote:
On Mon, Aug 01, 2011 at 02:12:51PM -0600, Eric Blake wrote:
> On 07/31/2011 10:58 PM, Lei Li wrote:
>> Make sure the unique storage pool defined and create from different directory to
avoid inconsistent version of volume pool created.
> Wrap your commit messages; typically at 70 columns or so (since 'git
> log' adds some indentation, but you want the end result to still fit
> in 80 columns for legibility).
>
>> Signed-off-by: Lei Li<lilei(a)linux.vnet.ibm.com>
>> ---
>> src/conf/storage_conf.c | 36 ++++++++++++++++++++++++++++++++++++
>> src/conf/storage_conf.h | 4 ++++
>> src/libvirt_private.syms | 2 ++
>> src/storage/storage_driver.c | 6 ++++++
>> 4 files changed, 48 insertions(+), 0 deletions(-)
>>
>> +virStoragePoolObjPtr
>> +virStoragePoolObjFindByPath(virStoragePoolObjListPtr pools,
>> + const char *path) {
>> + unsigned int i;
>> +
>> + for (i = 0 ; i< pools->count ; i++) {
>> + virStoragePoolObjLock(pools->objs[i]);
>> + if (STREQ(pools->objs[i]->def->target.path, path))
>> + return pools->objs[i];
>> + virStoragePoolObjUnlock(pools->objs[i]);
>> + }
>> +
>> + return NULL;
>> +}
> This one is good; in fact, we may even want to expose it as a public
> API, parallel to other virStoragePoolLookupBy* functions (but not
> until after 0.9.4 is released)
No, this API is flawed because def->target.path is not required to
be unique for all types of storage pool.
Daniel
And you said in the bug description that "The simplest example is two
directory pools that point to the same directory, but iSCSI and other pool types behave
similarly."
Based on your description, step to reproduce and expected results, I look at the code
about process of storage pool, I agree with your conclusion. But now I was confused for
your comment "target.path is not required to be unique for all types of storage
pool".
--
Lei