Re: [libvirt] [PATCH rfc v2 0/8] fspool: backend directory

On 09/21/2016 12:17 PM, Maxim Nestratov wrote: > >> 20 сент. 2016 г., в 23:52, John Ferlan <jferlan(a)redhat.com&gt; написал(а): >> >> >> >>> On 09/15/2016 03:32 AM, Olga Krishtal wrote: >>> Hi everyone, we would like to propose the first implementation of fspool >>> with directory backend. >>> >>> Filesystem pools is a facility to manage filesystems resources similar >>> to how storage pools manages volume resources. Furthermore new API follows >>> storage API closely where it makes sense. Uploading/downloading operations >>> are not defined yet as it is not obvious how to make it properly. I guess >>> we can use some kind of tar to make a stream from a filesystem. Please share >>> you thoughts on this particular issue. >> >> >> So how do you differentiate between with the existing <pool type="fs"> > > Pool type=fs still provides volumes, i. e. block devices rather than filesystem, though this storage pool can mount file systems resided on a source block device. > >> >> http://libvirt.org/storage.html#StorageBackendFS >> >> Sure the existing fs pool requires/uses a source block device as the >> source path and this new variant doesn't require that source but seems >> to use some item in order to dictate how to "define" the source on the >> fly. Currently only a "DIR" is created - so how does that differ from a >> "dir" pool. >> > > Same here, storage "dir" provides files, which are in fact block devices for guests. While filesystem pool "dir" provides guests with file systems. > > So then what is the purpose of providing a whole new storage driver subsystem? If you consider the existing storage driver is meant to handle storage pools of various types and the "pool" commands/API's are the "means" to manage those storage backend types, I'm still failing to see the advantage of (essentially) copying the storage driver when it seems you're really trying to write new backends that provide some specific functionality.

Having a guest mount a host file system would seem to be possible through other means. I also start wondering about security implications for either side (haven't put too much thought into it). What can the guest put "on" the host file system and vice versa where different security policies may exist for allowing such placement. Perhaps rather than a large dump of code the RFC should state the goal, purpose, usage, etc. and see if that's what the community wants or is willing to provide feedback on.