During manual resets, the drive was being identified by
idVendor, idProduct, and serial, what is NOT enough when
the USB device combines two or more drives.
For example the card reader Kingston MobileLite G3
supports two memory cards at the same time.
Discussion on the fixed issue is available here:
https://github.com/AltraMayor/f3/issues/10
User @derekchal was the first to report this problem.
When the memory card in a card reader is removed,
the device is kept, not removed like in the case
the reader itself is unplugged.
This patch handles the `change' events that are generated in
the card-removal case.
The field `Last good sector:' does not make sense
when the device is damaged, and
the geometry should be indepedent of the condition or
type of the drive.
The information is not lost because when the device "fixable",
f3fix is recommended with the correct parameter.
The new parameter allows users to test drives with
forced block sizes.
This parameter is only meant to help testing drives whose
*real* sizes are not multiples of their block sizes;
this should be rather rare!
This message is supposed to help the user to avoid
removing the drive after the last reset.
After a sequence of manual resets, it's almost automatic to unplug
the drive and lose all the save blocks; I've done it myself.
This patch makes f3probe test that the block device passed is
a disk, not a partition or something else.
If the block device is a partition,
the correct disk device is reported.
Example of this new protection in action:
$ sudo f3probe /dev/sdb1
[sudo] password for michel:
F3 probe 4.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
Device `/dev/sdb1' is a partition of disk device `/dev/sdb'.
You can run this program as follows:
f3probe /dev/sdb
Application cannot continue, finishing...
The code of the old manual reset couldn't handle the case of
the drive changing its filename, i.e. "/dev/sdb" becomes
"/dev/sdc" after the drive is unplugged and plugged back.
Not only this is a bug, in the rare case the user is
testing multiple drives at the same time, this would lead
to bad behavior.
Function map_block_to_usb_dev() was enumerating all USB devices and
comparing their properties to find the one we need.
The new code directly resolves the device from major and minor
number of the block device.
f3brew, f3 block read write, tests block devices
writing and reading blocks directly to devices.
This is a not-functional version of f3brew.
The main contribution of this patch is to reorganize libprobe.{h,c},
so f3brew, and any future application, can reuse the library.
One can write more blocks per pass in order to reduce
the total number of passes.
Trading resets for writes is effective when writing blocks is
cheaper than reseting the device being probed.
This patch dynamically balances the number of writes and
resets while probing.
The effectiveness of this balance is shown below:
A good 256MB drive produced the following measurements:
Probe time: 2.89 seconds
Probe read op: count=64, total time=0.13s, avg op time=2.06ms
Probe write op: count=48, total time=1.41s, avg op time=29.47ms
Probe reset op: count=8, total time=1.35s, avg op time=168.48ms
The results from previous commit (see git log):
Probe time: 47.57 seconds
Probe read op: count=2014, total time=1.72s, avg op time=0.85ms
Probe write op: count=2003, total time=45.32s, avg op time=22.62ms
Probe reset op: count=3, total time=0.53s, avg op time=175.66ms
Moreover, this patch spaces more uniformly
the blocks write_test_blocks() writes to improve
the effectiveness of each pass.
In order to reduce probing time, one needs to time
reads, writes, and resets to evaluate how to change
the probing algorithm.
This patch adds these measurements.
A good 256MB drive produced the following measurements:
Probe time: 47.57 seconds
Probe read op: count=2014, total time=1.72s, avg op time=0.85ms
Probe write op: count=2003, total time=45.32s, avg op time=22.62ms
Probe reset op: count=3, total time=0.53s, avg op time=175.66ms
Of all three operations called on the flash drive being probed
(i.e. reading blocks, writing blocks, and resetting the drive),
the most time-consuming operation is reliably resetting the drive.
This patch reduces the number of resets writing and reading
more blocks.
This option instructs f3probe to trade speed for less memory usage,
that is, f3probe minimizes use of memory.
Currently, this option only drops the use of the bitmap of
the safe device.
Nevertheless, this is not negligible memory.
For example, a 1TB drive whose block size is 512 Bytes requires
256MB of RAM for this bitmap:
1TB / 512Byte/Block = 2^31Block
2^31Block / 1Block/bit = 2^31bit
2^31bit / 8bit/Byte = 2^28Byte = 256MB
To put it in context, 256MB of RAM was all that
Raspberry Pi Model A had.
The current reset method isn't supported for all USB drives,
what leads to wrong conclusions about some fake drives.
The option --manual-reset allows users to unplug and plug back
the USB drive being tested to manually reset the drive.
This patch makes f3probe read and save in memory
the content of all written blocks before writting them
during the probe, and restore the original content of those blocks
after probing the device.
In order words, f3probe behaves likes the probed device were
read only.
All the necessary memory to protect the probed device is
preallocated, so an on-going probe does not fail due to
lack of memory.
Although this feature adds an important protection layer,
users should be conscious that things can go wrong, and
the data will be lost.
This patch also adds option --debug-keep-file to help debugging
the new code this patch adds, and option --destructive to disable
the protection.
