Add f3brew progress reporting

[darkk]

I've recently stumbled upon somewhat slow flash drive, that takes ~3 hours to go through f3brew cycle... But the flash drive is so cute and tiny that I decided to add a progressbar to f3brew instead of tossing the microSD-sized thumbdrive into trash bin 😆

Here is the patch adding a progressbar to f3brew.

Possible issue might come from fflush(stdout) for every written block of data as that might be somewhat slow on some incredibly slow terminals. On the other hand, I don't expect anyone to run f3brew over 9600 serial console and this behavior is also in sync with libflow.c, so this issue does not seem important to me.

Thanks for your awesome work and fighting the good fight.

[AltraMayor]

Hi @darkk,

First of all, thank you for your pull request. The proposed code adds a valuable feature to f3brew, and I'd like to see it merged. Would you consider rewriting the code to use libflow (i.e., files libflow.h and libflow.c) already in the repository?

Not only does libflow report progress, but it also optimizes the rate of writes and reads of the block in f3write and f3read. I expect that f3brew will be faster with this rewrite. You find examples of how to use libflow in f3write and f3read. The library libflow has been battle-tested in f3write and f3read, so the code is very well tested at this point.

I understand you've put time into your pull request and may feel disappointed with my feedback. I hope you can appreciate that the final product will be better, add less code to the repository, and make it easier for me to maintain it in the long run.

A small remark is that the repository code doesn't use // for comments but /* */.

[darkk]

@AltraMayor thanks for reply.

While I've seen libflow and it's capabilities, my assumption was that the code was for file-level I/O and it's API was a bit non-trivial as it combines a widget and IO via chunk-flush() callback. That's why I followed libeta way: a simplistic fixed-width widget with an estimator that is called every N units-of-work with poor-man's sliding window made of exponential damping and intentionally imprecise timer showing no seconds when it talks about hours.

I failed to wrap my head around libflow within a limited time-frame defined as "time during another disk is being tested". It has non-trivial amount of math and states. I believe it solves its complex task, but I don't really get it from the first sight.

So, it's unlikely that I'll be able to port f3brew to libflow in a foreseeable future (as "in the next weeks") as the API is not intuitive to me. I'm somewhat afraid that I'll break more code than I'll actually fix. And I have other projects going on as well 🙂 I'd be glad to refactor f3brew to give it a better progress-bar, but it's currently beyond my capacity. I'd say, it's even not that easy to reduce amount of widget redraws as validate_block() might print, so either the widget has to be cleared before each call to validate_block() or output should be carefully decoupled from validate_block() while testing all the edge cases. That's why I decided to do nothing about the number of fflush(stdout) calls for the moment.

Don't get me wrong, I'm not disappointed and I totally get your point. I agree that having one ETA widget is better than having two and having clean code is better than having dirty one.

Speaking of // and /* — pardon moi. Also, it would be really nice to have .clang-format file to make that explicit. I tried to generate one using clang-unformat, but it did not grok the style of comments correctly :-)

[AltraMayor]

It's okay to focus on your commitments. If you come around to work this out, keep in mind that you don't need to dive into the details of libflow, but to follow the usage examples in f3write and f3read. Moreover, having a pull request to only add libflow to the writing phase of f3brew would allow us to work together to get it right. After that pull request, another pull request to add libflow to the reading phase of f3brew should be more straightforward.