Re: [PATCH v2] storage: vz storage pool support

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

 



08-Dec-16 02:22, John Ferlan пишет:

[...]

I see what you mean; however, IMO vstorage should be separate. Maybe
there's another opinion out there, but since you're requiring
"something" else to be installed in order to get the WITH_VSTORAGE to be
set to 1, then a separate file is in order.

Not sure they're comparable, but zfs has its own. Having separated
vstorage reduces the chance that some day some incompatible logic is
added/altered in the *fs.c (or vice versa).
Ok. I will try.

I think you should consider the *_fs.c code to be the "default" of
sorts. That is default file/dir structure with netfs added in. The
vstorage may just be some file system, but it's not something (yet) on
"every" distribution.
I did not understand actually, what you mean  "be the "default" of sorts."
As I have understood - what I need to do is to create backend_vstorage.c
with all create/delete/* functionality.

Sorry - I was trying to think of a better way to explain... The 'fs' and
'nfs' pool are default of sorts because one can "ls" (on UNIX/Linux) or
"dir" (on Windows) and get a list of files.

"ls" and "dir" are inherent to the OS, while in this case vstorage
commands are installed separately.

Once you mounted your vstorage cluster to a local filesystem you can also "ls" it. Thus, I can't see much difference from nfs here.

When you create a vstorage "file" is that done via touch? or edit some
path or some other "common" OS command?  Or is there a vstorage command
that needs to be used.  If the former, then using the common
storage_backend API's should be possible.

vstorage is just another "remote filesystem" type of distributed software defined storage. In terms of starting to use it, it doesn't differ from nfs - you should mount it and then you can use any POSIX calls to control files and directories resided on it.

Maxim

John


Also I forgot to mention yesterday - you need to update the
docs/formatstorage.html.in at the very least and also the storage driver
page docs/storage.html.in.
In addition there are storagepool tests (xml2xml) that would need to be
updated to validate the new storage pool type. The tests would "show"
how the pool XML would appear and validate whatever parsing has been
done.
I know. Will fix.

[...]

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux