On 9/13/24 12:06, Jeffrey Walton wrote:
To add a datapoint...
My daily driver workstation is really fast with lots of RAM. It has
3.4 GHz cpu and 64 GB of RAM. I also set swappiness to a low value
to avoid spilling out of RAM.
I use a lot of SBC's/dev boards for testing. They usually use a
SDcard. The SDcard is really slow. The card can only provide 10 MB/s
or 30 MB/s write speeds. Some cards I use are so cheap they are even
slower.
If I dd an image from the workstation to the SDcard, it happens in
under a second. dd exits, and closes its file descriptors. Something
is obviously wrong since the image is 1 or 2 GB, and the SDcard write
speed is 10 MB/s or 30 MB/s.
The file system cache is still holding the writes. If I remove the
SDcard and try to use it, the image is corrupt. When I say "remove",
I mean pop the card out of the card reader since the write has
supposedly finished.
What I found is, I have to manually call sync to ensure the image is
written from cache to the SDcard. When I call `dd if=... of=/dev/sdd
&& sync`, the command takes 30 seconds or so to complete. The time is
spent in sync, not dd.
Based on my experience with lots of RAM and slow media, you have to
call sync to get the cache manager to write back to the disk.
That makes me think there is a bug in the secure digital card firmware,
the Linux secure digital card device driver, and/or the Linux file
system driver (?).
Have you seen a dd(1) invocation work correctly on a SD card without any
synchronization options and/or trailing sync(1)?
On 9/13/24 13:57, Rick Thomas wrote:
On the other hand, [running sync after dd] may not be necessary, but
it doesn't do any harm. If it is really unnecessary, it will probably
cost only a fraction of a second to do. And if it is actually
necessary, you should do it, no matter how long it takes.
+1
David
