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 valueto 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 writespeed 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 isspent 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