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 <[email protected]> wrote: > On Sat, Aug 6, 2016 at 7:37 AM, Niels de Vos <[email protected]> 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 >
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
