#1237 PR merged: Add (Linaro) flashbench to the list of PROGS¶
Labels: enhancement, fixed / solved / done
ProBackup-nl opened issue at 2017-03-11 12:56:¶
Flash memory, especially SD Cards and USB flash drives, often comes
without decent (NAND memory IC) specifications. As a result you have to
figure the optimal partition alignment value a.k.a. Allocation Unit,
a.k.a erase block size. That value is the smallest unit that a NAND
flash can erase. The values range from 128KB to 64MB, typically 2MB.
More info at
https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
The flashbench tool helps to identify the real world Allocation Unit
size for flash memory.
jsmeix commented at 2017-03-13 09:49:¶
@ProBackup-nl
I think there is a misunderstanding about what
the PROGS (and also the REQUIRED_PROGS) arrays
contain:
They contain the programs for the ReaR recovery system
(i.e. where "rear recover" is run).
I assume the flashbench tool is not needed during "rear recover".
gdha commented at 2017-03-13 11:04:¶
@ProBackup-nl is this flasbench tool meant for cloning purposes to a
different system using another type of SD card then the source? I have
no clue what I can do with it (as such)?
I found
https://github.com/bradfa/flashbench
as reference to the tool, I believe this is the one you are referring
to? Is this meant for all type of architectures?
ProBackup-nl commented at 2017-03-14 01:40:¶
@gdha Indeed, I mean
https://github.com/bradfa/flashbench.
Flashbench is not only for SD cards, or USB sticks, it is also
functional for SSD. I must admit that at NVMe interface speeds,
flashbench does no longer give usable output.
Flashbench helps you determine erase block size and page size. These
values help with more optimal partition alignment and more optimal file
system formatting.
Note: only necessary as long as the kernel is not able to determine these values from the drive, and manufacturers do not specify or even don't supply a datasheet (example Intel® SSD 600p Series, where I can only find a "Product Brief".
jsmeix commented at 2017-03-15 10:06:¶
I understand that flashbench helps with more optimal partition
alignment and more optimal file system formatting but those
tasks do usually not happen during "rear recover".
During "rear recover" the partitions and filesystems
should be re-created as much as possible exactly
as they had been on the original system.
Only in the so called "migration mode" when disks are
different on the replacement hardware during "rear recover"
optimal partition alignment should be done but even then
the filesystems should be still re-created as much as possible
exactly as they had been on the original system.
Because flashbench is menat for "flash memory devices"
according to
https://github.com/bradfa/flashbench
I think its usefulness during "rear recover" is rather limited,
namely only in the so called "migration mode" and
only for flash memory based disks (i.e. solid-state-drives).
I wonder if flashbench provides useful results for
professional solid-state-drives with a good controller
plus sufficient cache inside the solid-state-drive
so that a tool that runs outside of the solid-state-drive
may be basically unable to determine the physical block
size of the flash memory in the solid-state-drive.
Accordingly I assume flashbench is only useful
for cheap flash memory storage devices
a.k.a. cheap USB memory sticks.
Summary:
From my current point of view I think flashbench in
the ReaR recovery system is not really useful.
In the future this might change (i.e. when cheap flash
memory storage devices get usually used in computers).
Note the difference:
I think flashbench could be really useful for the "rear format"
workflow which is intended to be used to prepare a cheap
USB memory stick to be used as ReaR recovery medium.
schlomo commented at 2017-03-15 10:36:¶
I would like to suggest a compromise: Let's include flashbench
together with code that actually uses it during recovery. Till then you
can always add it yourself in your configuration with
PROGS+=(flashbench). In any case I expect most installations to have a
site.conf with their own stuff in it.
+1 for using it in rear format, again please submit code and not just
the tool include.
About flashbench itself: IMHO this is a good idea as more and more
disks are flash based. If I had a server with an old hard disk I would
actually consider replacing it with an SSD if it breaks down.
jsmeix commented at 2017-03-16 10:55:¶
@schlomo
regarding replacing a traditional spinning disk with an SSD
and then appropriate partitioning alignments:
I think doing by default parted partition alignments
simply at 8 MiB block size in "migration mode"
would be "the right thing" in almost all cases, cf.
the new USB_PARTITION_ALIGN_BLOCK_SIZE
and
https://github.com/rear/rear/issues/1201
Accordingly I think a new issue would make sense
to enhance the "migration mode" to support a general
PARTITION_ALIGN_BLOCK_SIZE variable that is
by default set to 8 MiB.
gdha commented at 2017-03-22 13:01:¶
@ProBackup-nl Will you add some additional code or documentation around
the usage of flashbench?
You can always write some document for the doc section. It would be very
interesting read for lots of people? Thank you for bringing this new
tool to my attention.
[Export of Github issue for rear/rear.]