Very Computer

Tell me this isn't so. I am developing an app on Linux that relies
on disk files to pass data between differents processes. In debugging
this app I discovered that in many occasions the data written to the
file was not flushed to disk until the file was closed! This app relies
heavily on disk I/O and I posted a question recently on how to tune the
Linux disk cache for optimum performance (I received only one reply
that said that Linux uses all available free memory for disk cache).

Anyway is it true that I have to close and reopen the file after EACH
write to insure it is written to disk so this or another process can
read it? This seems like very strange behavior as even if the data is
in a memory resident cache, when a read occurs for that data it should
be retrieved from the cache or disk. Please help me understand this.

Thanks....

Please E-mail and I will summarise.

Don Rubin

Unfortunatly I am not using buffered streams, I am using plain old
open(...) and write(...), and as far as I can tell there is no corresponding
flush(...) for nonbuffered I/O

Quote:> 2) If you are using disk files to exchange data between processes,
> there is no telling what else you are doing, and so it is hard to help
> you with your problems: You should have included the code you are
> using to write to the file.

The code is rather lengthy and I am requesting some general information
rather than a "bug" fix to my code. In particular if I write to a file,
do an lseek to somewhere, do a read, then lseek back to the first place
I wrote and try to read it, the data is not correct unless I close and
re-open the file. I could probably post a trivial example of this
but I wonder if this is known behavior (ie. having to close after a write
to flush it to disk) OR if I have a wierd problem.

Quote:> 3) Pipes or sockets are a better idea, if you want to transfer data
> between processes. Sockets are fascinating and they are What Is Done.

Thanks very much for the suggestion. As it turns out this is a network server
program and does use sockets to exchange data between clients (what a
concept!). However for this program I need to implement persistant queues
to have other processes on this machine process the data retreived by this
network server. My implementation must be portable to other Uni so I
can't use shared memory to implement the queues. I decided on disk files
as queues using flock to mediate access. "What Is Done" to implement
persistant queues?

Don Rubin                             Voice: 301-588-8010
Systems Engineering Technology Inc.   Fax:   301-588-0154

Silver Spring, MD 20910-1121          http://www.setinc.com
                                      finger for PGP public key

There is no need for one, the fflush() call just calls write() in any
data buffered in memory.  When you use write() the data will be put in
the disk cache and be scheduled for write without flush request.

Quote:>> 2) If you are using disk files to exchange data between processes,
>> there is no telling what else you are doing, and so it is hard to help
>> you with your problems: You should have included the code you are
>> using to write to the file.
>The code is rather lengthy and I am requesting some general information
>rather than a "bug" fix to my code. In particular if I write to a file,
>do an lseek to somewhere, do a read, then lseek back to the first place
>I wrote and try to read it, the data is not correct unless I close and
>re-open the file. I could probably post a trivial example of this
>but I wonder if this is known behavior (ie. having to close after a write
>to flush it to disk) OR if I have a wierd problem.

You probably have a bug in the code somewhere...  All I ever tried in
this direction worked without closing the file.

You could mmap() the file and just write in the mapped area, but frankly
I would expect more trouble with that, than with write().
(writing in an mmap'ed file was unsupported for a long time, and I don't
know how well it works now)

Rob
--
+------------------------------------+--------------------------------------+


+------------------------------------+--------------------------------------+

I think you've got it!  The fsync() call does the trick. Can you point
me to some info about programming memory mapped files? That might be
a better/faster solution to my disk based queues.

Thanks to all that responded. I appreciate the help.

Don Rubin                             Voice: 301-588-8010
Systems Engineering Technology Inc.   Fax:   301-588-0154

Silver Spring, MD 20910-1121          http://www.setinc.com
                                      finger for PGP public key

How about fflush(3)?

Johan.

--

| Astronomical Observatory  | WWW       http://www.astro.uu.se/~jl/ |
| Box 515                   | Phone     (+46) (0)18 513522          |
| S-751 20 Uppsala, SWEDEN  | Fax       (+46) (0)18 527583          |

sync(2)

This is true, but it should not be necessary.
Reads from the file are done via the same cache as writes, so when you
read data you should get the correct values even when the block has not
yet been written to disk.

If this does not work, it is a kernel bug.

Rob
--
+------------------------------------+--------------------------------------+


+------------------------------------+--------------------------------------+

Quote:>How about fflush(3)?

How about reading the question first?

Rob
--
+------------------------------------+--------------------------------------+


+------------------------------------+--------------------------------------+

Have you looked into using sockets or shared memory to do this? It could
result in a big performance increase.

Quote:> >In debugging
> >this app I discovered that in many occasions the data written to the
> >file was not flushed to disk until the file was closed! This app relies
> >heavily on disk I/O and I posted a question recently on how to tune the
> >Linux disk cache for optimum performance (I received only one reply
> >that said that Linux uses all available free memory for disk cache).

> Right-o. The operating system (Linux) buffers reads and writes to the
> physical media. Linux has a dynamic buffer/page cache, which can grow
> quite large. Every 30 seconds or so update/bdflush flushes all
> modified pages in the cache to disk. You can do this yourself
> by calling the synx(2) system call.

It is desirable to use free memory for disk cache because this dynamic cache
is invisible to user programs. They cannot tell if they are reading from
disk or from cache except by the speed, and changes are automatically
available to other programs.

Quote:> You can also open the file for synchronous writes. If you do this,
> the process will block until the data is physically on the disk, so
> you'll know it's there. Do this:

>         int fd = open("/tmp/shoop", O_WRONLY| O_SYNC| O_CREAT);

But there are other levels of caching going on. Don probably doesn't want
to do this unless he is paranoid about data loss due to crashes or power
outages.

If he is able to tell from the shell that the file "wasn't written out,"
then he is probably seeing stdio file buffering.

When you use fopen(), fprintf(), fputs(), etc, the C library buffers
the transfers by holding the data in memory until it fells like it has
accumulated enough to justify actually writing to the file. To get around
this use fflush(). This is also useful for terminal IO when you want to print part of a line without the newline.

You could also just use the open(), read(), and write() calls since they
do not have additional buffering (as far as I know anyway :).

-Ross