The vast majority of the time it takes to do mkfs.gfs2 is spent
writing the journals. In theory, we should be able to use function
warm_fuzzy_stuff() from fsck/util.c or adapt function
big_file_comfort from the same fsck/util.c.

(In reply to Robert Peterson from comment #2)
> The vast majority of the time it takes to do mkfs.gfs2 is spent
> writing the journals.

I don't think that's true since https://git.fedorahosted.org/cgit/gfs2-utils.git/commit?id=7c0e7b3a58 - I believe the bottleneck for smaller devices is the quota change file creation now, although a performance improvement in that area is on the cards.

However, this bz was created with very large devices in mind and the mkfs performance characteristics for those are different, as resource group creation time scales up with device size but i/o related to journal/quota change creation doesn't.

Also, I filed this bz after testing on a large thinp volume which does discards very slowly. So, I think we should split the (uninterruptible) discard operation into chunks at some point - as part of this bz or later - and additionally update the new progress indicator between chunks.

Created attachment 1084404 [details]
Patch - Add progress bar to mkfs.gfs2

Here is a Patch posted upstream to the Master branch. It adds a simple progress bar to mkfs.gfs2 which is utilised when building both the journals and resource groups.

Is the progress bar only shown when stdout is a tty?  I don't really want to see test logs filling up with tons of progress bar output.

(In reply to Nate Straz from comment #6)
> Is the progress bar only shown when stdout is a tty?

It's not a progress "bar" as such, but it doesn't print the intermediate "[2/4]" updates when stdout isn't a tty, only the "Done" at the end of the section:

16:11:50 andy@plato mkfs 0$ ./mkfs.gfs2 -Oplock_nolock -j4 -b512 sparsefile &>mkfs.log 
16:13:19 andy@plato mkfs 0$ cat mkfs.log 
It appears to contain an existing filesystem (gfs2)
This will destroy any data on sparsefile
Adding journals: Done
Building resource groups: Done
Creating quota file: Done
Writing superblock and syncing: Done
Device:                    sparsefile
Block size:                512
Device size:               1024.00 GB (2147483648 blocks)
Filesystem size:           1024.00 GB (2147483645 blocks)
Journals:                  4
Resource groups:           4098
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      5712c0f0-d133-ebc3-df1c-80e1f2d8e2db

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=498444

Verified in gfs2-utils-3.1.9-3.el7:

[root@south-16 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.9-3.el7.x86_64
[root@south-16 ~]# mkfs.gfs2 -p lock_nolock -t test:progress /dev/sdb1
This will destroy any data on /dev/sdb1
Are you sure you want to proceed? [y/n]y
Discarding device contents (may take a while on large devices): Done
Adding journals: Done 
Building resource groups: Done       
Creating quota file: Done
Writing superblock and syncing: Done
Device:                    /dev/sdb1
Block size:                4096
Device size:               1791.57 GB (469649399 blocks)
Filesystem size:           1791.57 GB (469649398 blocks)
Journals:                  1
Resource groups:           7167
Locking protocol:          "lock_nolock"
Lock table:                "test:progress"
UUID:                      bf7494b6-0e8c-b837-6b84-53b41030b188

Added some information to the doc text field regarding the feature of the enhancement as requested by Milan Navratil.

"mkfs.gfs2 reports its progress to tell that it is still alive in the event of a long mkfs"

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://rhn.redhat.com/errata/RHBA-2016-2438.html