insufficient memory on armhf platform
I'm successfully using f3probe on my laptop. Thank you for this great tool.
I recently set up a Banana Pi SBC computer (armv7 armhf) and thought it would be cool to test this tool out on that platform. Agreed, the SBC is fairly limited but I thought 1GB of RAM and an additional 512GB of flash ought to be enough to run this tool. It isn't
pi@banana:~$ sudo f3probe /dev/sdb
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
Out of memory, try `f3probe --min-memory /dev/sdb'
pi@banana:~$ sudo f3probe --min-memory /dev/sdb
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
Out of memory, try `f3probe --destructive /dev/sdb'
Please back your data up before using option --destructive.
Alternatively, you could use a machine with more memory to run f3probe.
pi@banana:~$ free
total used free shared buff/cache available
Mem: 1016592 254072 174940 29552 657052 762520
Swap: 508292 0 508292
Have you tried --destructive?
Without the argument --destructive, f3probe requires ~4GB of memory to back up all written blocks to the tested drive. This is a conservative approach meant to help users avoid losing data. If you're okay with formatting the drive after the test, the argument --destructive is fine and should work.
Thank you for that explanation.
I have not yet used the destructive option as I am still talking to the seller to get a refund.
In the meantime, I added a larger 4GB swap thinking this would be enough to get the software running. It wasn't. I guess my issue is not platform-specific, after all. Does f3probe really require that much RAM or shouldn't it be possible to cache some information on disk or offload it to swap temporarily? I understand priorities, time constraints, etc. I'm really just curious and asking to understand better. I am certainly happy to test my cards on the laptop but I think from an intellectual POV it would also be nice to test the nice program on a few more exotic platforms ;-)
Thanks, again, for the tool and your time to drop by and give me an explanation as to why I ran into this issue in the first place.
f3probe allocates all the backup memory with a single malloc(3). Add 6GB of swap instead of 4GB since the kernel and other processes also need memory. And check if there's some memory limit being enforced on f3probe and other processes. If this doesn't solve the problem, check if the platform can allocate ~4GB with a single malloc(); this requires 64-bit memory space.