f3 icon indicating copy to clipboard operation
f3 copied to clipboard

Add note on f3probe assumptions to readme

Open jowagner opened this issue 5 years ago • 5 comments

Add paragraph to readme explaining f3probe assumption and ask for reports on drives with different behaviour

jowagner avatar Sep 01 '20 12:09 jowagner

Here a first draft. I also included a few words on f3write/read as a section technical details without this would be odd.

I did git rebase -i master as suggested (after syncing my master with your master). Not sure whether it is normal/a problem that the other change(s) now appear under "file(s) changed".

jowagner avatar Sep 02 '20 15:09 jowagner

A few more lines to explain what f3read checks and how errors are reported.

jowagner avatar Sep 02 '20 16:09 jowagner

I added verbose output in https://github.com/jowagner/f3/tree/verbose and I now doubt I understand correctly how f3probe operates. Each line between the "Writing" lines shows how many blocks are validated by printing a v for each call of is_block_good(). f3probe writes a lot more data to the flash disk than I expect from my understanding of the code so far. Furthermore, if the search for bad blocks is a binary search and the search area doubles in size in each step the number of blocks verified in each step should increase at least by 1 in each step. However, the number of blocks verified in each step appears to be constant. It is still possible that the description in this PR is accurate but I cannot tell at the moment. Pease review carefully.

$ fdisk -l /dev/sdc
Disk /dev/sdc: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: Micro Line      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ ./f3probe --destructive --time-ops /dev/sdc
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.


Writing 2048 blocks from 61437952 to 61439999.

Writing 4096 blocks from 61433856 to 61437951.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Writing 8192 blocks from 61425664 to 61433855.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Writing 16384 blocks from 61409280 to 61425663.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Writing 32768 blocks from 61376512 to 61409279.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Writing 65536 blocks from 61310976 to 61376511.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Writing 131072 blocks from 61179904 to 61310975.
^C

jowagner avatar Sep 03 '20 11:09 jowagner

In order to avoid duplicate patches in this pull request, you need to git rebase master at your branch. You should git push --force afterward.

On the question of what f3probe is doing at the beginning of the process, it's trying to find the size of the cache of the drive. See find_cache_size() for details.

AltraMayor avatar Sep 03 '20 12:09 AltraMayor

Thanks for the pointers, also in the related issue. I hope to find time soon to investigate a bit more so I can finalise the text.

jowagner avatar Sep 08 '20 10:09 jowagner