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<[email protected]>
---
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
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
