TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: ALL
from: DENNIS LEE BIEBER
date: 2019-10-30 11:16:00
subject: Re: SDCardKiller

On Tue, 29 Oct 2019 20:25:22 -0500, Knute Johnson
 declaimed the following:

>of 4096 bytes the block size from the Java FileStore.  So a randomly
>selected file name is checked for existence, if it doesn't exist I write
>409,600 bytes of 1s to the file.  If it does exist and it has 1s in it I
>write 409,600 0s to the file.  If it has 0s in it, I delete it.  I do

 Since most flash memory erases to 1s, the first half is mostly a no-op.
The card obtains an allocation unit from its free-list, erases it, and then
essentially does nothing but declare the sectors in use as writing all 1s
to a unit filled with 1s makes no changes.

 1-bits can be changed to 0-bits but I doubt the SD card controller chip
is smart enough to realize it can do an in-place update -- so again the
card will obtain a free allocation unit, erase it to 1s (and copying any
data belonging to other unopened files to the unit), then write 0s to the
sectors of the opened file.

 This is also why "secure file erase" can't really be done on flash
memory. The common secure erase is to write a random pattern, then invert
the pattern and write over the file, and finally write another random
pattern -- but on flash memory, each write is going to a different part of
the memory as part of wear-leveling and routine allocation unit
assignments.

https://raspberrypi.stackexchange.com/questions/32884/why-does-the-sd-card-rand
om-write-performance-for-record-size-8-128-kb-drops-bel
https://www.raspberrypi.org/forums/viewtopic.php?t=11258
From the latter URL:

 On a Beaglebone Black

debian@beaglebone:~$ cat /sys/block/mmcblk0/device/preferred_erase_size
4194304
debian@beaglebone:~$ cat /sys/block/mmcblk1/device/preferred_erase_size
4194304
debian@beaglebone:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev              220096       0    220096   0% /dev
tmpfs              49496    5508     43988  12% /run
/dev/mmcblk0p1   7572696 2847372   4366564  40% /
tmpfs             247476       0    247476   0% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs             247476       0    247476   0% /sys/fs/cgroup
tmpfs              49492       0     49492   0% /run/user/1000
debian@beaglebone:~$

 mmcblk0 is an 8GB SanDisk Edge C-4 SD card, mmcblk1 is the on-board 4GB
eMMC.

 For an R-Pi 3B+

pi@rpi3bplus-1:~$ cat /sys/block/mmcblk0/device/preferred_erase_size
4194304
pi@rpi3bplus-1:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root       12028584 6626000   4768524  59% /
devtmpfs          469544       0    469544   0% /dev
tmpfs             474152       0    474152   0% /dev/shm
tmpfs             474152    6404    467748   2% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             474152       0    474152   0% /sys/fs/cgroup
/dev/mmcblk0p6    258094   53034    205060  21% /boot
tmpfs              94828       0     94828   0% /run/user/1000
pi@rpi3bplus-1:~$

 16GB Kingston C-10 SDHC card


 If the systems aren't lying about the "preferred" size, then all of
these are using 4MB erase sizes -- 10 times the arbitrary file size you've
defined -- so on average, you are going to undergo 10 times the erase
cycles since each erase unit has 10 files in it (ignoring Linux inode and
journal updates).

 I did kill an SD card on an R-Pi 3B many years ago -- running the HINT
benchmark on it with a swap file on the SD card (I later bought a 1TB USB
hard drive to use for swap, reran the benchmark on the R-Pi and then on a
BBB). I should spend time some day recompiling the benchmark -- though it
does show the impact of Linux (at the time, the main usage was to benchmark
a No-OS embedded board, so no overhead from an OS, and the benchmark would
shut down when an attempt to malloc a large memory block fails -- on Linux
the OoM Killer, uhm, kills the benchmark before it can report results; swap
file/disk allows the benchmark to do one pass with swapping at which point
it determines performance is falling off too much and shuts down on its
own)





--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.