On a gluster volume with 100GB if we try to create a gluster-block of size 100GB with pre-allocation, block creation succeeds but it silently fails to allocate the correct sizes for the shards on the posix xlator.
sh-4.2# du -sh .shard/* | awk '{print $1}' | sort | uniq -c
1 18M
1 26M
1597 64M
Because of this when writes happen on a pre-allocated block device, writes fail with ENOSPC which shouldn't happen for preallocated files.
REVIEW: https://review.gluster.org/20254 (storage/posix: Handle ENOSPC correctly in zero_fill) posted (#1) for review on master by Pranith Kumar Karampuri
COMMIT: https://review.gluster.org/20254 committed in master by "jiffin tony Thottan" <jthottan> with a commit message- storage/posix: Handle ENOSPC correctly in zero_fill
Change-Id: Icc521d86cc510f88b67d334b346095713899087a
fixes: bz#1590710
Signed-off-by: Pranith Kumar K <pkarampu>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report.
glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.
[1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html
[2] https://www.gluster.org/pipermail/gluster-users/
On a gluster volume with 100GB if we try to create a gluster-block of size 100GB with pre-allocation, block creation succeeds but it silently fails to allocate the correct sizes for the shards on the posix xlator. sh-4.2# du -sh .shard/* | awk '{print $1}' | sort | uniq -c 1 18M 1 26M 1597 64M Because of this when writes happen on a pre-allocated block device, writes fail with ENOSPC which shouldn't happen for preallocated files.