Hey folks,
Wanted to check if anyone out here uses BTRFS (and willing to share
their experiences[1]) as the backend filesystem for GlusterFS. We're
planning to explore some of it's features and put it to use for
GlusterFS. This was discussed briefly during the weekly meeting on
#gluster-meeting[2].
To start with, we plan to explore data/metadata checksumming (+
scrubbing) and subvolumes to "offload" the work to BTRFS. The
mentioned
features would help us with BitRot detection[3] and Openstack Manila use
cases respectively (though there are various other nifty things one
would want to do with them).
Thanks in advance!
[1]: using any of it's features such as snapshot, data/metadata
checksumming, etc. as an added functionality for Gluster
[2]:
http://meetbot.fedoraproject.org/gluster-meeting/2014-09-24/gluster-meeting.2014-09-24-12.07.log.html
[3]:
http://www.gluster.org/community/documentation/index.php/Features/BitRot
Venky
On 09/25/2014 12:23 PM, Venky Shankar wrote:> Hey folks, > > Wanted to check if anyone out here uses BTRFS (and willing to share > their experiences[1]) as the backend filesystem for GlusterFS. We're > planning to explore some of it's features and put it to use for > GlusterFS. This was discussed briefly during the weekly meeting on > #gluster-meeting[2]. > > To start with, we plan to explore data/metadata checksumming (+ > scrubbing) and subvolumes to "offload" the work to BTRFS. The > mentioned features would help us with BitRot detection[3] and > Openstack Manila use cases respectively (though there are various > other nifty things one would want to do with them).From openstack Manila perspective, I think this will be useful in the following ways: 1) subdir level snapshot can help gluster-nfs driver of Manila and root level snap can help gluster native driver of Manila to implement cheap (in terms of resources) snapshot support. 2) Not sure if create from snapshot semantic is supported by btrfs, if yes that could be useful too. 3) copy offload if supported 4) data shredding (not sure if btrfs has support for it?) Also in order for Manila to use/exploit these feature, there must be a way to expose these as capabilities in the gluster cli. That ways openstack ( liek any other consumer of gluster) can query for the capabilities and if present can provide the functionality to the end user. So i guess this work should go along with ability to expose capabilities of the bricks/volume in gluster. My few cents ;-) thanx, deepak> > Thanks in advance! > > [1]: using any of it's features such as snapshot, data/metadata > checksumming, etc. as an added functionality for Gluster > [2]: > http://meetbot.fedoraproject.org/gluster-meeting/2014-09-24/gluster-meeting.2014-09-24-12.07.log.html > [3]: > http://www.gluster.org/community/documentation/index.php/Features/BitRot > > Venky
On Thu, Sep 25, 2014 at 12:23 PM, Venky Shankar <vshankar at redhat.com> wrote:> Hey folks, > > Wanted to check if anyone out here uses BTRFS (and willing to share their > experiences[1]) as the backend filesystem for GlusterFS. We're planning to > explore some of it's features and put it to use for GlusterFS. This was > discussed briefly during the weekly meeting on #gluster-meeting[2]. > > To start with, we plan to explore data/metadata checksumming (+ scrubbing) > and subvolumes to "offload" the work to BTRFS. The mentioned features would > help us with BitRot detection[3] and Openstack Manila use cases > respectively (though there are various other nifty things one would want to > do with them). >>From openstack Manila perspective, I think this will be useful in thefollowing ways: 1) subdir level snapshot can help gluster-nfs driver of Manila and root level snap can help gluster native driver of Manila to implement cheap (in terms of resources) snapshot support. 2) Not sure if create from snapshot semantic is supported by btrfs, if yes that could be useful too. 3) copy offload if supported 4) data shredding (not sure if btrfs has support for it?) Also in order for Manila to use/exploit these feature, there must be a way to expose these as capabilities in the gluster cli. That ways openstack ( liek any other consumer of gluster) can query for the capabilities and if present can provide the functionality to the end user. So i guess this work should go along with ability to expose capabilities of the bricks/volume in gluster. My few cents ;-) thanx, deepak> Thanks in advance! > > [1]: using any of it's features such as snapshot, data/metadata > checksumming, etc. as an added functionality for Gluster > [2]: http://meetbot.fedoraproject.org/gluster-meeting/2014-09- > 24/gluster-meeting.2014-09-24-12.07.log.html > [3]: http://www.gluster.org/community/documentation/index. > php/Features/BitRot > > Venky > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140926/2c6c2986/attachment.html>
On Thu, Sep 25, 2014 at 2:53 AM, Venky Shankar <vshankar at redhat.com> wrote:> Hey folks, > > Wanted to check if anyone out here uses BTRFS (and willing to share their > experiences[1]) as the backend filesystem for GlusterFS. We're planning to > explore some of it's features and put it to use for GlusterFS. This was > discussed briefly during the weekly meeting on #gluster-meeting[2]. > > To start with, we plan to explore data/metadata checksumming (+ scrubbing) > and subvolumes to "offload" the work to BTRFS. The mentioned features would > help us with BitRot detection[3] and Openstack Manila use cases respectively > (though there are various other nifty things one would want to do with > them). > > Thanks in advance!Hey, I couldn't make the meeting, but I am interested in BTRFS. I added this in puppet-gluster a bunch of months ago as a feature branch. https://bugzilla.redhat.com/show_bug.cgi?id=1094860 I just pushed it to git master. https://github.com/purpleidea/puppet-gluster/commit/6c962083d8b100dcaeb6f11dbe61e6071f3d13f0 The reason I want btrfs support, is I want glusterfs to eventually be able to support reflinks across gluster volumes. There is a strong use case for this feature. Let me know if this helps! Cheers, James
On 25/09/2014, at 7:53 AM, Venky Shankar wrote: <snip>> Wanted to check if anyone out here uses BTRFS (and willing to share their experiences[1]) as the backend filesystem for GlusterFS. We're planning to explore some of it's features and put it to use for GlusterFS. This was discussed briefly during the weekly meeting on #gluster-meeting[2].In last week's GlusterFS Community Meeting, I volunteered to get a VM up and running in Rackspace so people could start getting btrfs testing happening. The requested OS was Fedora 21 (alpha) as it has newer versions of stuff than in Fedora 20. However, I'm having some real problems getting F21 up and running in Rackspace. In a local VM on my desktop, no issue. In Rackspace though, it never (ever) comes back from the reboot after the upgrade. (suspecting due to the PVHVM nature of the VM maybe) How critical is it for this to be F21 instead of F20? If it's really important, then I'll start getting really creative to get F21 on there. But it's likely to be a bit of a time suck with experimentation. Or would F20 (extremely easy to do) be good enough for now? Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift