On Wed, 30 Oct 2019 10:41:31 -0500, Knute Johnson
 declaimed the following:

>
>So would it make more sense to just write a file of 0s and then erase
>it?  And to change the file size to 4MB?  Or does every write to a file
>whether the same data or not cause an erase and a write to a different
>block?  I which case we could just write 0s to the file over and over again.

 Since I don't think the card controller chips check for whether a bit
will change, the simple view would be that writing even one bit to a file
will require the card to pull a free "unit", erase it, then copy allocated
sectors/block/clusters from the original unit that belong to /other/ files,
then start adding the new data to what were unallocated sectors in that
"unit".

 Cards can keep some number of "units" "open" (cheap cards keep 2 units
open -- which basically means for FAT format, the FAT/bitmap is in one
unit, and one unit can be getting data written to it [typically, one output
file, but on a freshly erased card, it might be possible to have multiple
output files interleaving at the sector level]). Open "units" are buffered
in RAM in the card controller chip. Journaling file systems will do a lot
of unit swapping on such a cheap card -- on a card with a 6 open unit
ability, it may be possible to keep the journal, bitmap, and multiple
output files in different units and the card only really flushes /to/ the
flash when it fills a "unit" and needs to fetch a new one.

https://opensource.com/article/17/5/introduction-ext4-filesystem
"""
Instead of writing data to the disk's data areas directly, as in previous
versions, the journal in EXT3 writes file data, along with its metadata, to
a specified area on the disk. Once the data is safely on the hard drive, it
can be merged in or appended to the target file with almost zero chance of
losing data. As this data is committed to the data area of the disk, the
journal is updated so that the filesystem will remain in a consistent state
in the event of a system failure before all the data in the journal is
committed. On the next boot, the filesystem will be checked for
inconsistencies, and data remaining in the journal will then be committed
to the data areas of the disk to complete the updates to the target file.
"""

 The journal scheme basically means that writing to a file actual writes
the data somewhere in the journal first, then writes the journal metadata
that describes what is in the journal... Some time later, the OS merges
that data with the real file followed by clearing out the relevant
metadata. So you have the possibility that even writing one byte to a file
triggers up to four unit erase/rewrite operations (all handled by the card
controller chip; a card with 6-unit capability may not have written the
journal unit to flash, and also may have a unit for the journalled data and
a unit for the actual file buffered).


"""
EXT4 reduces fragmentation by scattering newly created files across the
disk so that they are not bunched up in one location at the beginning of
the disk, as many early PC filesystems did. The file-allocation algorithms
attempt to spread the files as evenly as possible among the cylinder groups
and, when fragmentation is necessary, to keep the discontinuous file
extents as close as possible to others in the same file to minimize head
seek and rotational latency as much as possible. Additional strategies are
used to pre-allocate extra disk space when a new file is created or when an
existing file is extended. This helps to ensure that extending the file
will not automatically result in its becoming fragmented. New files are
never allocated immediately after existing files, which also prevents
fragmentation of the existing files.
"""

 Note that EXT4 is actually designed to NOT create adjacent/interleaved
files -- so expect to use one "unit" per open output file. Obviously the
seek and latency concerns don't apply to an SD card, since wear levelling
will scatter the "logical blocks" willy-nilly.



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

--- SoupGate-Win32 v1.05