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. /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
