Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes
On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
> David Wright <deblis@lionunicorn.co.uk> writes:
> > On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
> >> David Christensen <dpchrist@holgerdanske.com> writes:
> >>
> >> > 2. sync(1) is unnecessary.
> >>
> >> Does it even do anything wrt device files? sync(2) says "sync() causes
> >> all pending modifications to filesystem metadata and cached file data to
> >> be written to the underlying filesystems."
> >
> > I think you also need to read the other manpage, fsync(2).
>
> 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)).”
as in fsync(2)'s Description, as opposed to sync(2)'s Bugs:
“According to the standard specification (e.g., POSIX.1-2001), sync()
schedules the writes, but may return before the actual writing is
done. However, since version 1.3.20 Linux does actually wait. (This
still does not guarantee data integrity: modern disks have large
caches.)”
Cheers,
David.
Reply to: