On Sun, Feb 14, 2016 at 06:56:16AM -0500, Donald Allen wrote:

> On Sun, Feb 14, 2016 at 1:43 AM, Tinker <ti...@openmailbox.org> wrote:
> 
> > Did two tests, one with async and one with softdep, on amd64, 5.9-CURRENT,
> > UFS.
> >
> > (Checked "dd"'s sources and there is no fsync() anywhere in there.
> >
> > The bufcache setting was 90, 3GB free RAM, pushed 2GB of data using "dd"
> > to disk.
> >
> 
> Based on knowledge of Unices from long ago (not on direct knowledge of
> OpenBSD internals), I believe 'dd' uses raw I/O, which bypasses the buffer
> cache.
> 
> Those who know the details better than I should comment and correct me if
> I'm wrong, but if I'm right, your test doesn't prove anything about
> file-system write caching because your writes didn't go through the
> file-system.

Depends where you are writing to: a file or a device?

        -Otto

> 
> /Don Allen
> 
> >
> > It took 12 and 15 seconds respectively, which is the harddrive's write
> > speed - the buffer cache of course would have absorbed this in 0 seconds.)
> >
> >
> > So, both runs showed that OpenBSD *not* does any write caching to talk
> > about, at all.
> >
> >
> > This means if a program wants write caching, it needs to implement it
> > itself.
> >
> > Good to know.
> >
> > Tinker
> >
> >
> > On 2016-02-13 23:47, Tinker wrote:
> >
> >> Hi,
> >>
> >> How much of my file writing, and filesystem operations such as
> >> creating a new file/directory, will land in OpenBSD's disk/write cache
> >> without touching the disk before return of the respective operation to
> >> my program, for softdep or async UFS media and I never fsync() ?
> >>
> >>
> >> This is relevant to know for any usecase where there may be a big
> >> write load to a magnet disk *and* there's lots of RAM and "sysctl
> >> kern.bufcachepercent" is high.
> >>
> >> If those ops will be done in a way that is synchronous with the magnet
> >> disk, the actual fopen(), fwrite(), fread() (for re-read of the data
> >> that's been written but still only is in the OS RAM CACHE) etc. might
> >> be so slow that a program would need to implement its own write cache
> >> for supporting even small spikes in write activity.
> >>
> >> Sorry for the fuss but neither "man" nor googling taught me anything.
> >>
> >> Thanks!!
> >> Tinker

Reply via email to