The write and read buffers passed to the operating system have
previously been limited to MAX_BUFFER_SIZE. This commit makes
them dynamically sized in order to reach maximum writing and
reading speeds.
See details on issue #188.
The original libflow was written for f3write only, and
this was reflected in the name of fields and variables
throughout the code. This patch renames these fields and
variables to reflect the fact that libflow will eventually
support f3write AND f3read.
NVM drives are fast enough to overflow 32-bit measurement variables
in bytes and blocks. This patch upgrades these variables to 64 bits.
This patch addresses issue #117:
https://github.com/AltraMayor/f3/issues/117
The file system HFS (i.e. "OS X Extended (Journaled)") of
macOS 10.11 may return a number of partial write()'s before
the file system is full.
This POSIX-permited, but unusual behavior was frist reported here:
https://github.com/AltraMayor/f3/issues/111
According to issue #102, calls to fdatasync() might take
a long time (.e.g. 3s or 4s) and distort the measurement of
the average write speed. This patch addresses it by only updating
the measurements when delays are within a tolerance.
When measure() fails at the very last end of a file,
@remaining is zero.
Since @saved_errno is not ENOSPC, but @remaining is zero,
the code was considering that the file was properly written.
This parameter is useful to test cards that overheat.
Daniel Otero (@danielotero) pointed out the overheat problem, and
suggested the parameter as a solution in the following issue:
https://github.com/AltraMayor/f3/issues/37
This patch combines many calls to system call write() into
a single call.
This lower number of calls, and the combined buffer should enable
the kernel to speed up f3write to match H2testw' performance as
reported in the following issue:
https://github.com/AltraMayor/f3/issues/55
This patch improves the progress percentage and estimate of
time to finish when option --end-at requires f3write to write
less than the amount of free space available.
This parameter allows users to execute F3 concurrently.
Moreover, users Mark and Wolfi have asked for similar parameters to
help analyzing very large flash drives.
Now F3 and h2testw share the same file format.
Guenter Knauf has suggested this feature and
got the random-number generator used in h2testw from
Harald Bogeholz, the author of h2testw.
This change also addresses the issue that
the original random-number generator only fills
the first 32 bits of the 64 bits of the random numbers on
64-bit machines.
Besides the lower entropy on 64-bit machines, this issue was
making files generated on 32-bit and 64-bit machines incompatible.
Anselm Distelrath was the first to report this issue.
This parameter became important because F3 now can be used on
very large storages and one may want to resume the test process
from a failure or interruption.
Messages like "Removing old file 0001.fff ..." were issued in
a file system dependent order.
This is a cosmetic change that takes advantage of
the function ls_my_files previously created for f3read.
The original algorithm had a slow reaction when there was
a large variation on the flow capacity.
The new algorithm even removed the need for the call to sync(2)
at beginning.
If an F3 file (i.e. *.fff) but the last one is missing,
f3read will report the missing file with a warning similar to this one:
Missing file 0001.fff
AND the following warning will be presented at the end of the report:
WARNING: Not all F3 files are available
Kenneth Arnold suggested this feature in an e-mail:
"I also noticed that if one of the files is completely missing, f3read
will still report no errors. The chance that this will happen on its
own without messing something else up is too small to worry about,
except possibly in the case that the device was actually read-only and
no files actually got created. In that case, f3read succeeds with 0
sectors OK and 0 sectors lost."
The last F3 file, if missing, is not reported because
it can be confusing.
The following example gives an idea of the problem:
a memory card wasn't empty when f3write was called and
the last F3 file created was 0010.fff with exactly 1GB;
here none F3 file is missing.
Then, some non-F3 files were removed, and f3read is called.
f3read would report a missing file even when non-F3 files were
removed!
The problem gets a little bit uglier if 0010.fff in the example
is less that 1GB, or the file system doesn't let f3write to
fill it up for a few bytes (this should be very rare, but
there's no guarantee that it cannot happen).
Finally, the implementation of this feature has a positive
side effect: f3read processes F3 files in ascending order,
that is, 0001.fff, 0002.fff, ..., NNNN.fff.
Before the order was file system dependent.
Magic numbers related to the number of digits in the F3 files'
names were eliminated.
In the previous version of f3write, fdatasync(2) was used to
show the progress printouts smoothly.
However, it slows down a lot the execution, and hurts
the writing speed measurement.
This new version finds out what is the writing speed of
the memory card being tested using an algorithm that reseables
TCP's congestion control algorithm, and keeps writing at that
speed; this allows smooth progress printouts.
f3write is even faster now!
* f3read
As long as the kernel honors our advice, f3read doesn't
ever read data from the system cache instead of reading
from the memory card, and reading speed measurement is
improved.
* f3write
Progress printout goes smoothly now.
See file Documentation/CodingStyle in Linux's source code
for a reference of the style.
Used "indent -kr -i8" to help out.
Added a .gitignore to the repository.
Nobody has reported this "bug", neither have I seen it coming out,
but I'm fixing it anyway.
It's based on Kenneth Arnold's fork of F3, which is available here:
https://github.com/kcarnold/f3
I also added a few lines in README.
