Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #273070

Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

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

Show all headers | View raw


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


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