[Gluster-devel] Deprecation of striped volumes as 'feature' for 3.9

Krutika Dhananjay kdhananj at redhat.com
Fri Aug 12 10:01:30 UTC 2016


So sharding in its current form should still work fine in the non-VM-store
use-cases
as long as they are single-writer-to-large-file workloads.

I am starting (actually resuming :)) work on making it useful for
multiple-writers workload.
Sharding will need to use locks to synchronize modification (inode writes
mostly)
fops from multiple clients to the same file. To this end, we will need a
common
transaction framework that can eliminate the need for multiple lock
requests from
different translators on the client stack as part of the same transaction,
if we want the
solution to yield good performance. This plus consumption of composite fops
plus delayed
updates (xattrop) to global size are some of the things I need to complete
before sharding
can be used in multiple-writers workload. I will be posting updates on
gluster-devel as and
when I make progress on this.

-Krutika




On Fri, Aug 12, 2016 at 9:24 AM, Vijay Bellur <vbellur at redhat.com> wrote:

> On Sat, Aug 6, 2016 at 7:37 AM, Niels de Vos <ndevos at redhat.com> wrote:
> > Hi,
> >
> > As *we* all are aware, striped volumes should not be used anymore. The
> > replacement for this is sharding, available and stable since the latest
> > 3.7 releases and 3.8. Unfortunately users still create striped volumes,
> > and some even write blog posts with examples.
> >
> > We should actively recommend users not to use striping anymore. This is
> > a proposal to remove the striping xlator from the GlusterFS sources over
> > the next two releases:
> >
> >  - 3.9: prevent creation of new striped volumes, warn in the client logs
> >         when striping is used
> >
>
> One possibility would be to recommend sharding instead of striping in
> the CLI whenever a stripe volume creation is attempted in 3.9.
>
> Krutika - how far are we from sharding being used for general workloads?
>
> Thanks,
> Vijay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160812/f93c4aa9/attachment-0001.html>


More information about the Gluster-devel mailing list