Bug 1196321
Summary: | [RFE] Add a progress indicator to mkfs.gfs2 | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Andrew Price <anprice> | ||||
Component: | gfs2-utils | Assignee: | Paul Evans <pevans> | ||||
Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | ||||
Severity: | low | Docs Contact: | Milan Navratil <mnavrati> | ||||
Priority: | low | ||||||
Version: | 7.2 | CC: | cluster-maint, gfs2-maint, jpayne, mnavrati, pevans, royoung, rpeterso, swhiteho | ||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | gfs2-utils-3.1.9-1.el7 | Doc Type: | Release Note | ||||
Doc Text: |
A progress indicator has been added to `mkfs.gfs2`
The `mkfs.gfs2` tool now reports its progress when building journals and resource groups. As `mkfs.gfs2` can take some time to complete with large or slow devices, it was not previously clear if mkfs.gfs2 was working correctly until a report was printed. A progress bar has been added to `mkfs.gfs2` indicate progress.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-11-04 06:29:47 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: | |||||||
Bug Depends On: | 1271674 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Andrew Price
2015-02-25 17:05:03 UTC
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 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 |