On Fri, Sep 13, 2024 at 03:00:14PM +0300, Anssi Saari wrote:
> David Wright <deb...@lionunicorn.co.uk> writes:
>
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
>
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
>
> > “fsync() transfers ("flushes") all modified in-core data of (i.e.,
> > modified buffer cache pages for) the file referred to by the file
> > descriptor fd to the disk device (or other permanent storage device)
> > so that all changed information can be retrieved even after the
> > system crashed or was rebooted. This includes writing through or
> > flushing a disk cache if present. The call blocks until the device
> > reports that the transfer has completed. It also flushes metadata
> > information associated with the file (see stat(2)).”
>
> You just parroted a man page I had already read. Why did you think
> that'd be helpful? I asked the questions because the man page didn't
> answer my questions. As you are apparemntly unable [...]Please, Anssi. You can do better than that. > [...] I found for example > https://unix.stackexchange.com/questions/473854/block-device-cache-v-s-a-filesystem > and so arrived to the conclusion that the final close(2) call on a block > device already flushes all buffers before returning. So the answer to > the question "is running sync needed after dd to block device" is > no. Someone else posted that too on this list recently, in another > thread. So I did an (admittedly very rough) experiment, and this seems to confirm the above: tomas@caliban:~$ time sudo dd if=/dev/zero of=/dev/sdb bs=1M ; time sync dd: error writing '/dev/sdb': No space left on device 15268+0 records in 15267+0 records out 16008609792 bytes (16 GB, 15 GiB) copied, 3614.25 s, 4.4 MB/s real 60m14.260s user 0m0.005s sys 0m0.007s real 0m0.077s user 0m0.002s sys 0m0.000s I interpret that this way: after 16G of dd (the stick is 16G) there isn't a significant amount of buffers lying around waiting to be flushed to the stick (it's a slow USB, as suggested by the 60m the dd took, so if there were a lot of buffers, we'd see more than .077 sec for the sync). The box has plenty of RAM (16G) for what it's doing (14G free), so there is no particular memory pressure which would favour quick flushing of buffers. So yes, it seems when the dd is done, it's done. Cheers -- t
signature.asc
Description: PGP signature
