On Wed, Sep 28, 2016 at 10:09:34PM +0530, Prasanna Kalever wrote: > On Wed, Sep 28, 2016 at 11:24 AM, Muthu Vigneshwaran > <mvignesh@xxxxxxxxxx> wrote: > > > > Hi, > > > > This an update to the previous mail about Fine graining of the > > GlusterFS upstream bugzilla components. > > > > Finally we have come out a new structure that would help in easy > > access of the bug for reporter and assignee too. > > > > In the new structure we have decided to remove components that are > > listed as below - > > > > - BDB > > - HDFS > > - booster > > - coreutils > > - gluster-hdoop > > - gluster-hadoop-install > > - libglusterfsclient > > - map > > - path-converter > > - protect > > - qemu-block > > Well, we are working on bringing qemu-block xlator to alive again. > This is needed in achieving qcow2 based internal snapshots for/in the > gluster block store. We can keep this as a subcomponent for now. > Take a look at http://review.gluster.org/#/c/15588/ and dependent patches. Although we can take qemu-block back, we need a plan to address the copied qemu sources to handle the qcow2 format. Reducing the bundled sources (in contrib/) is important. Do you have a feature page in the glusterfs-specs repository that explains the usability of qemu-block? I have not seen a discussion on gluster-devel about this yet either, otherwise I would have replied there... Nobody used this before, and I wonder if we should not design and develop a standard file-snapshot functionality that is not dependent on qcow2 format. Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
