On Thu, May 25, 2017 at 11:35 AM, Jaden Liang <liangzijie@xxxxxxxxx> wrote:
This requires architecture change where we know the location of each file rather than each brick.
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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
