On Thu, May 25, 2017 at 11:35 AM, Jaden Liang <liangzi...@gmail.com> wrote:
> Hi all, > > As I know, glusterfs have to replace brick to rebuild replica when some > bricks go down. In most commercial distributed storage system, there is a > key spec that indicates how fast to rebuild data when some components > broke. In glusterfs, the replace-brick operation only use 1 on 1 to rebuild > replica, this can not use the cluster disks performance to increase the > rebuild job that some companies called it RAID2.0. Therefore, I have some > thoughts what to discuss. > > Glusterfs use one single storage graph in a volume, like M x N > distributed-replicated volume. This storage graph is global for all files > in the same volume. From what I know in VMWare vSAN, vSAN use different > graphs for different files, which means, every file has its own storage > graph. In this case, file replica rebuild or file rebalance could do mush > flexible than single global graph. If some brick goes down, it can just > modify those storage graphs of files which lost replica, then rebuild can > be run which replace-brick operations. > This requires architecture change where we know the location of each file rather than each brick. > > Just a thought, any suggestion would be great! > There are efforts under way to make self-heal comparable to rsync, would that help? > > Best regards, > Jaden Liang > 5/25/2017 > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel