On 09/23/2016 11:45 AM, Daniel P. Berrange wrote: > On Fri, Sep 23, 2016 at 11:38:10AM -0400, John Ferlan wrote: >> >> >> On 09/21/2016 12:17 PM, Maxim Nestratov wrote: >>> >>>> 20 сент. 2016 г., в 23:52, John Ferlan <jferlan@xxxxxxxxxx> написал(а): >>>> >>>> >>>> >>>>> 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. > > This is a completely different beast to the existing storage pools > driver code. > > Ultimately the difference here is about what's being managed. The > existing storage pools code is managing storage volumes, which are > essentially blobs which are used to provide virtual disks. > > This FS pools code is about managing filesystem trees, which are > essentially directories used to provide filesystem passthrough > feature for guests, most compelling for containers. > > Trying to shoe-horn both concepts into the same API is really > not very attractive, as you have fundamentally diffrent logic > requirements for managing the entries in the respective pools > OK fair enough, might be something worth of adding to the description (cover letter). Whether it's documented further in the patches I didn't check. The whole series is a 8 rather mostly large patches. I think the other point/concern is that it appears as if the fspool driver was started by copying storage_driver and then hacking out what wasn't needed, rather than deciding what needs to be there to build up such a fs pass through driver. At least that's my impression from scanning the first couple of patches. For example, patch 1 first file - libvirt-fs.h it's essentially libvirt-storage.h copied with some things removed. The first enum has all build and build overwrite flags. Doesn't seem any of those are used in the driver code on a quick scan. The create with build flag was added to allow someone to combine those pool-create and pool-build type functions because for some backends it doesn't make sense to "build" as it's already there. That to me seems like it could be a "design decision" for this new driver. Does a FS pool need to handle build with [no] overwrite? What would overwrite be? I think rather than just copy what the storage pool does, I would think the new driver could "build up" what it needs based on some consensus based on what makes sense for the usage model. >> 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. > > This was previously done in the mailing list many months ago now. > Well a pointer would have been nice... Obviously I didn't remember it! There was an fspools v1 posted 8/19. I think there was an assumption that list readers/reviewers would remember some original RFC. I didn't. I've just been going through older patches that haven't had review and this just came up as "next" (actually I had started thinking about the v1 when v2 showed up). John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list