Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #273070
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes |
| Date | 2024-09-14 01:40 +0200 |
| Message-ID | <Jmo3n-c5dk-7@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <JkMMy-b5Pb-15@gated-at.bofh.it> <Jl4T7-bgM9-1@gated-at.bofh.it> <JmdhD-bYSL-7@gated-at.bofh.it> <JmdhD-bYSL-5@gated-at.bofh.it> <JmjQ5-c2Ol-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Disk drive zero-fill benchmarks for various synchronization methods and block sizes David Christensen <dpchrist@holgerdanske.com> - 2024-09-08 20:10 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-09 11:00 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes David Wright <deblis@lionunicorn.co.uk> - 2024-09-09 15:40 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-10 11:00 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-13 14:10 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes <tomas@tuxteam.de> - 2024-09-13 20:40 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Michael Stone <mstone@debian.org> - 2024-09-16 04:50 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes <tomas@tuxteam.de> - 2024-09-16 06:40 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Jeffrey Walton <noloader@gmail.com> - 2024-09-13 21:10 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes David Christensen <dpchrist@holgerdanske.com> - 2024-09-14 01:40 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-16 11:10 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes <tomas@tuxteam.de> - 2024-09-16 11:20 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-16 12:50 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes <tomas@tuxteam.de> - 2024-09-16 13:00 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Michael Stone <mstone@debian.org> - 2024-09-16 13:20 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes "Rick Thomas" <rick.thomas@pobox.com> - 2024-09-13 23:20 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes David Wright <deblis@lionunicorn.co.uk> - 2024-09-16 21:20 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Michael Stone <mstone@debian.org> - 2024-09-16 05:00 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-16 12:20 +0200
Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes Michael Stone <mstone@debian.org> - 2024-09-16 13:40 +0200
csiph-web