GNOME Bugzilla – Bug 697662
Do not hide the progress of the tools used
Last modified: 2013-09-18 16:54:39 UTC
One of the key features in 0.15 was live tracking of the command progress output in the details log. gparted, however, asks the tools to not show the progress by passing a --no-progress-bar param (or a short equivalent, e.g. "ntfsresize -P ..."). Because of this, the new progress output is kinda useless, as it does not provide any useful information. In case of ntfsresize for example, only the version is shown. It would be really helpful, if you could remove these (hard coded?) params. http://gparted-forum.surf4.info/viewtopic.php?id=16858
Created attachment 241106 [details] [review] Ntfsresize progress (v1) Here's a patch which removes the -P flag from ntfsresize. Also pleasant surprised when the saved operation details only includes 100% complete and not hundreds of line showing every displayed %age. Hope there aren't any other file system command we are suppressing useful %ages or progress bars from. Thanks, Mike
Thank you for the bug report and the patch. The patch looks good to me, and I plan to test it tomorrow before committing it to the git repository. Mike, If you have time, it might be worth checking the copy, resize, and check-repair operations for other file systems to ensure that these are not suppressing text progress information. Curtis
Hi Curtis, I've read the manual pages of most of the file system specific commands we used and found these: 1) ext2/3/4 - Could add "-C 0" to e2fsck to add an ascii text progress bar. 2) fat16/32 - Could add "-l" to dosfsck to list file being processed. 3) reiser4 - Could remove "--quiet" from fsck.reiser4 to allow gauges. 4) reiserfs - Could remove "--quiet" from reiserfsck to display rate of progress. 5) xfs - Could add "-p seconds" to either xfsdump or xfsrestore to print progress every so many seconds. 6) xfs - Could add "-t seconds" to xfs_repair to report progress every so many seconds. I didn't see anything relevant for: btrfs, hfs, hfsplus, jfs, linux_swap, lvm2 pv and nilfs2. I'll have a look at coding these at the weekend. You can test the current patch if you want as I won't change that. Thanks, Mike
Hi Mike, Wow, it looks like you've found quite a few areas for potential improvement. Since I am currently trying to get a MythTV PVR repaired/upgraded due to a failed hard drive, I will hold off on testing until later. Cheers, Curtis
This appears to be a dup of Bug 467925 - gparted: add progress bar during operation, which has patches waiting for review.
Hi Mike, I think it is still worthwhile to proceed with this patch, especially with our indecision on bug #467925, and because comment #3 identifies more file system that might be improved. What do you think? Curtis
I'll have a closer look at the other file systems to see what's suitable.
Created attachment 254355 [details] [review] Ntfsresize progress (v2) Hi Mike, I have taken the liberty of rebasing your patch from comment #1 against the current git master branch. If possible, I would like to include this fix in the 0.16.2 release because many of our users work with NTFS file systems. I have reviewed the patch and all looks well to me. If you are in agreement, we can commit this patch to the git repository. Regards, Curtis
Created attachment 254435 [details] [review] Ntfsresize progress (v3) Hi Curtis, I had actually done 90% of what I said I would look at in comment #3. Just never got around to finishing it off. Here's version 3. Changes: (1) Patch: Allow ntfsresize command to report real-time %age progress (#697662) Very small comment change. Drop "Closes". (2) New patch: Enable %age complete display from e2fsck command (#697662) Thanks, Mike
And when I tested the file system tool progress indicators, here's why I decided not to add them to GParted: 1) ext2/3/4 file system resize "resize2fs -p ..." Draws 3 progress bars from 0 to 40 'X's. No indication to the user how many 'X's will be drawn or a percentage as there is with e2fsck. Don't use. 2) fat16/32 file system check "fsck.fat ... -l ..." Lists every file name being checked. GParted's operation output and log file shows all files. File names are updated *VERY* fast causing GParted to use 100% CPU time. A large number of files displayed also causes GParted to hang for minutes while displaying the operation output. Don't use. 3) reiserfs file system check "reiserfsck ..." without --quiet flag Reiserfsck updates VERY quickly causing GParted to use ~70% CPU time just displaying the output in the operation dialog. Don't use. 4) reiser4 file system check "fsck.reiser4 ..." without --quiet flag Can't test. Assume the same as for reiserfs. Don't use. 5) xfs file system copy "xfsdump -p 10 ..." and/or "xfsrestore -p 10 ..." Print a progress statement every 10 seconds. For even modist file systems printing a couple lines of text every 10 seconds quickly adds up to a lot of output to display in the operation dialog. Don't use. Never properly tested the xfs_repair case.
1) For me, the output of resize2fs looks like: Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks. Begin pass 2 (max = 29815167) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 36670) Scanning inode table XXXXXXXXXXX----------------------------- it seems to be quite obvious that every '-' will be replaced by an 'X' as the process proceeds and s.o. can guess if the resize will take about 10 minutes or about 10 houres. 2) "-l List path names of files being processed." is undoubtedly superfluous 3-4) IMHO detailed output of the file system checks is not that important as they can be run easily before starting GParted Regards, Tom
Hi Mike and Tom, 1) Thank you Tom for your feedback and indicating how "resize2fs -p" works from a terminal. Unfortunately the printing of the initial dashes is undone with the current asynchronous output handling in the GParted GUI. This is because we use CR's and Backspaces to remove output from the log file. This keeps the log file down to a reasonable size. As such when "-p" is added to the "resize2fs" command, the user will only see "X"s growing across the screen, and not know how many to expect. Since changing this handling for a single command is non-trivial, and likely not desired, I think it best to leave improving resize2fs progress for the following report: Bug #467925 - gparted: add progress bar during operation 2-5) Agreed. My review and testing of the patch set in comment #9 has gone well. As such I have committed this patch set to the git repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Allow ntfsresize command to report real-time %age progress (#697662) https://git.gnome.org/browse/gparted/commit/?id=a8b699d896a329c66d412032d7f33139d9a0538d Enable %age complete display from e2fsck command (#697662) https://git.gnome.org/browse/gparted/commit/?id=59a22673da55eb185b8bd1e25cc9a729e24c24bb Curtis
The patches to address this report have been included in GParted 0.16.2 released on September 18, 2013.