GlusterFS as block storage

[anon314159]

Hello everyone,

While I am aware of the gluster-block project, it seems development has frozen and will remain this way indefinitely. I digress, from a practical perspective is it feasible to serve out block storage via sparse files and TargetCLI (iSCSI) or loop devices? The goal is to leverage Gluster's HA and data resiliency (Erasure Codes or Replication) features on the backend but serve out large (100+TB's) 'image files' as raw block storage (SAN). This primarily seeks to overcome the LOSF/LOF issues with Glusterfs as well as reduce the metadata overhead associated with storing millions of files and further fanout I/O across bricks.

Below are conceptual maps/topologies demonstrating two possible designs:

iSCSI:
https://docs.gluster.org/en/latest/Administrator-Guide/GlusterFS-iSCSI/
Hardware ->GlusterFS -> Volume -> FUSE Mount -> Sparse_File.img ->TargeCLI (Target) ->Windows/Linux iSCSI (initiator) ->NTFS/XFS

SMB/NFS:
Hardware ->GlusterFS -> Volume -> FUSE Mount -> Sparse_File.img -> XFS -> Loop device Mount -> SMB/NFS

The sparse image file is formatted with XFS, mounted as a loop device (ex. mount -t xfs Sparse_File.img -o loop), and then export the mount as file storage via SMB or NFS.

I have conducted small scale testing (10TB sparse file) using both of the above options with a reasonable degree of success. Assuming the volume or sub volumes bricks are large enough, what (if any) are the size constraints for a single "image" file and are there any additional caveats to either setup? I was concerned about issues with silent data corruption occurring with very large files or a heal operation tainting the internal data structures, but there's nothing really stating this isn't technically achievable (could vs. should seems to apply in this situation). Thanks again.