On Thu, May 25, 2017 at 11:35 AM, Jaden Liang 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
