When a new volume is created and/or when a brick is added to an existing volume, it should make sure that the backend file system type (ext3 | xfs | ext4) is the same in all the bricks.
Why is this a bug? Why should such a check be performed?
(In reply to comment #1) > Why is this a bug? Why should such a check be performed? We may not have found a bug yet, but there are bound to be differences between file systems even when they are posix compliant. Furthermore, there are performance differences between file systems which will make life difficult for us. Too many variables is not good for predictability / supportability and I do not see a reason for why one would want such a setup.
Not sure at what layer the fix is planned, but we need to fix our gluster-provision-* commands too so as to take care of this scenario in our appliances.
Lets not prevent it as such, but warn the user while doing 'volume create' about the heterogeneous backend systems.
Kaushik already started work on this issue, so he will continue with this.
Planing to keep 3.4.x branch as "internal enhancements" release without any features. So moving these bugs to 3.4.0 target milestone.
I've been using heterogeneous bricks; creating new bricks as XFS because of the ext4 problem when using recent kernels. So far, no issues. Updating the documentation with a recommendation (presumably against) would be helpful.
Concluded that this is not to be done as it is not a requirement, and hinders testing of glusterfs. Having homogeneous bricks is not a must.