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.

Bug 1769786

Summary: mkfs.xfs should print a message about BLKDISCARD when enabled
Product: Red Hat Enterprise Linux 7 Reporter: Jon Magrini <jmagrini>
Component: xfsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED ERRATA QA Contact: Zorro Lang <zlang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.8CC: fsorenso, jshivers, preichl, pvlasin, rhandlin, xzhou
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: FutureFeature
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-29 20:41:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jon Magrini 2019-11-07 13:17:16 UTC
Description of problem:

Default option for mkfs.xfs enables BLKDISCARD ioctl() on devices which support it, which can take quite a long time without providing any feedback to the user or progress, rather it looks like the command is hung. This RFE is to request an informational message printed to warn the user that mkfs might take a while when the underlying block device supports discards.  

Version-Release number of selected component (if applicable):

xfsprogs-4.5.0-20.el7
xfsprogs-5.0.0-1.el8

How reproducible:
Very

Steps to Reproduce:
1. Create a filesystem on a block device which supports discard requests


Actual results:
On very large filesystems the mkfs.xfs operation can take some time with no status or progress message indicating what mkfs is doing. 

Expected results:

Print a basic msg on creating informing the user that the requested action may need lengthy time to complete. 


Additional info:

Comment 3 Jon Magrini 2019-11-07 13:43:50 UTC
Just digging around xfsprogs briefly, a simple print statement could be added: 

--- xfs_mkfs.c.bak	2019-11-05 10:22:48.754396459 -0500
+++ xfs_mkfs.c	2019-11-05 10:25:34.782969469 -0500
@@ -2127,6 +2127,7 @@ _("warning: sparse inodes not supported
 	}
 
 	if (discard && !Nflag) {
+		printf("%s", _("Discard enabled (may take a while): "));
 		discard_blocks(xi.ddev, xi.dsize);
 		if (xi.rtdev)
 			discard_blocks(xi.rtdev, xi.rtsize);

Comment 4 Jacob Shivers 2019-11-11 15:09:36 UTC
Thoughts on a RFE request would involve something like putting the BLKDISCARD ioctl() into a child process and have epoll_pwait wait on some signal for the ioctl() to return. After some predetermined timeout, epoll_pwait would expire and proceed as if the ioctl() received ENOTTY to avoid a hang on the ioctl() syscall as it is currently implemented.

This seems a bit of belt and suspenders deployment, but I am curious as to what others think.

Comment 5 Eric Sandeen 2019-11-11 15:53:45 UTC
As of now, most major filesystems implement discard by default.  It was originally envisioned that discard would be primarily an accounting action, that it would therefore be quick, and that starting "fresh" at mkfs time would make sense.  It might be time to re-evaluate that.


btrfs does state that it's doing the trim (discard):

# ./mkfs.btrfs -f /dev/loop1
btrfs-progs v5.3 
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM /dev/loop1 (1.00GiB) ...

mke2fs also announces it:

mke2fs /dev/loop1 
mke2fs 1.43.7 (16-Oct-2017)
Discarding device blocks: done

Lukas added this functionality for e2fsprogs:

commit 7d9e31655fca48e9d6c2647ad443124113508b73
Author: Lukas Czerner <lczerner>
Date:   Mon Jan 24 20:52:00 2011 +0100

    mke2fs: Display progress report during the device discard

        For some time now we are doing initial discard of the device prior to
    filesystem creation. However, there is no feedback for the user and
    hence on some devices with slow TRIM implementation it may appear that
    mke2fs is stuck.

and it probably does make sense to add this same info to mkfs.xfs - we'll look into it.

Thanks,
-Eric

Comment 6 Eric Sandeen 2019-12-12 14:36:50 UTC
Pavel has sent a patch upstream to implement the e2fsprogs approach, and it has been reviewed and will soon be merged.

Comment 11 Eric Sandeen 2020-05-18 17:32:31 UTC
Removing "FutureFeature," printing 1 informational line is not really a feature.

Comment 14 Zorro Lang 2020-06-07 14:26:19 UTC
Old xfsprogs mkfs.xfs output:
# mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


mkfs.xfs from xfsprogs-4.5.0-22.el7 output:
# mkfs.xfs -f /dev/loop0
Discarding blocks...Done.
meta-data=/dev/loop0             isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

It prints "Discarding blocks...Done" about BLKDISCARD.

Comment 16 errata-xmlrpc 2020-09-29 20:41:49 UTC
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 (xfsprogs bug fix and enhancement update), 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/RHBA-2020:4028