Subject: Re: fsync performance hit on 1.6.1
To: Daniel Brewer <firstname.lastname@example.org>
From: Chuck Silvers <email@example.com>
Date: 07/07/2003 09:33:27
oh, for the file in the MFS you shouldn't need any kind of syncing at all.
the data will be available in memory for the second process to read
immediately after the write() returns. this is true for both 1.6.x and 1.5.x.
On Mon, Jul 07, 2003 at 09:45:23AM +0200, Daniel Brewer wrote:
> For our application, we have 1 process capturing images from a frame-grabber
> and dumping them to a file in a memory file system. It sends a UDP message
> to another process that reads the images from this file and writes them to
> disk in a database. The first process has to guarantee that after it's done
> writing that image to the memory file system, that it is actually there for
> the second process to read. The problem is slightly more complicated, as we
> have systems out in the field running 1.5.1 which we still need to support.
> I've tried opening the file with O_SYNC and not doing the fsync(). On 1.5.1,
> this has increased the write() time slightly, which was expected, but the
> overall processor utilization hasn't changed much. On 1.6.1, this has the
> same impact as just removing the fsync() - which I expected because of the
> MNT_SYNCHRONOUS flag in the mfs mount in 1.6.1. So far, I haven't had any
> problems with this solution. Will this solution guarantee that whatever the
> first process writes is there for the second process to read?