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);

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.

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

Pavel has sent a patch upstream to implement the e2fsprogs approach, and it has been reviewed and will soon be merged.

Removing "FutureFeature," printing 1 informational line is not really a feature.

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.

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