Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When I grow a GFS2 file system the successful output includes an error about fallocate not being supported.
[root@host-135 ~]# df -h /mnt/growfs0/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/growfs-growfs0 300G 259M 300G 1% /mnt/growfs0
[root@host-135 ~]# lvs growfs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
growfs0 growfs -wi-ao---- 300.00g
[root@host-135 ~]# lvextend -L 400G growfs/growfs0
Size of logical volume growfs/growfs0 changed from 300.00 GiB (76800 extents) to 400.00 GiB (102400 extents).
Logical volume growfs/growfs0 successfully resized.
[root@host-135 ~]# lvs growfs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
growfs0 growfs -wi-ao---- 400.00g
[root@host-135 ~]# gfs2_grow /mnt/growfs0/
FS: Mount point: /mnt/growfs0
FS: Device: /dev/mapper/growfs-growfs0
FS: Size: 78643199 (0x4afffff)
DEV: Length: 104857600 (0x6400000)
The file system will grow by 102400MB.
fallocate: Operation not supported <--- HERE
gfs2_grow complete.
[root@host-135 ~]# echo $?
0
[root@host-135 ~]# df -h /mnt/growfs0/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/growfs-growfs0 400G 259M 400G 1% /mnt/growfs0
I ran the command with strace and found that gfs2_grow is trying to fallocate on the rindex on the gfs2metafs.
18856 open("/tmp/.gfs2meta.xvHEtj/rindex", O_RDWR|O_CLOEXEC) = 6
...
18856 fallocate(6, 01, 15648, 96) = -1 EOPNOTSUPP (Operation not supported)
The file system does grow and appears to be completely usable.
Version-Release number of selected component (if applicable):
gfs2-utils-3.1.9-3.el7.x86_64
kernel-3.10.0-514.el7.x86_64
How reproducible:
Easily
Steps to Reproduce:
See example above.
Actual results:
Odd error message is printed
Expected results:
No odd error message during a successful command.
Additional info:
gfs2_grow uses
if (fallocate(rindex_fd, FALLOC_FL_KEEP_SIZE, (rindex_size + writelen), entrysize) != 0)
perror("fallocate");
to allocate enough space to write an rindex entry if the fs is full when the next grow happens. So, while the grow will succeed, the danger of the fallocate() failing is that a second gfs2_grow could fail if the fs is full.
After a recent change to fix bug 1221331, gfs2's fallocate implementation does:
if ((mode & ~FALLOC_FL_KEEP_SIZE) || gfs2_is_jdata(ip))
return -EOPNOTSUPP;
and since mkfs.gfs2 creates the rindex inode with GFS2_DIF_JDATA set, the gfs2_is_jdata(ip) returns true and we see the bug.
So I'm not sure that we can fix this in gfs2_grow. We may need to allow gfs2's fallocate to proceed for the rindex especially, or for all GFS2_DIF_SYSTEM inodes.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2017:1842
Description of problem: When I grow a GFS2 file system the successful output includes an error about fallocate not being supported. [root@host-135 ~]# df -h /mnt/growfs0/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/growfs-growfs0 300G 259M 300G 1% /mnt/growfs0 [root@host-135 ~]# lvs growfs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert growfs0 growfs -wi-ao---- 300.00g [root@host-135 ~]# lvextend -L 400G growfs/growfs0 Size of logical volume growfs/growfs0 changed from 300.00 GiB (76800 extents) to 400.00 GiB (102400 extents). Logical volume growfs/growfs0 successfully resized. [root@host-135 ~]# lvs growfs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert growfs0 growfs -wi-ao---- 400.00g [root@host-135 ~]# gfs2_grow /mnt/growfs0/ FS: Mount point: /mnt/growfs0 FS: Device: /dev/mapper/growfs-growfs0 FS: Size: 78643199 (0x4afffff) DEV: Length: 104857600 (0x6400000) The file system will grow by 102400MB. fallocate: Operation not supported <--- HERE gfs2_grow complete. [root@host-135 ~]# echo $? 0 [root@host-135 ~]# df -h /mnt/growfs0/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/growfs-growfs0 400G 259M 400G 1% /mnt/growfs0 I ran the command with strace and found that gfs2_grow is trying to fallocate on the rindex on the gfs2metafs. 18856 open("/tmp/.gfs2meta.xvHEtj/rindex", O_RDWR|O_CLOEXEC) = 6 ... 18856 fallocate(6, 01, 15648, 96) = -1 EOPNOTSUPP (Operation not supported) The file system does grow and appears to be completely usable. Version-Release number of selected component (if applicable): gfs2-utils-3.1.9-3.el7.x86_64 kernel-3.10.0-514.el7.x86_64 How reproducible: Easily Steps to Reproduce: See example above. Actual results: Odd error message is printed Expected results: No odd error message during a successful command. Additional info: