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)
|