| Roger Leigh 2005-01-13, 5:53 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matty <matty@daemons.net> writes:
> I have been digging through books for the past few days trying to find
> out how the Solaris kernel handles a close() operation. Given the
> following sequence of system calls:
>
> fd = open("logfile", O_APPEND);
> write(fd, "blah", 4);
> close(fd);
> exit(0);
>
> When would "blah" actually get written to the file referenced by fd?
When the kernel feels like it, basically. If you want to guarantee
the data is physically on the disk, you can:
- - open with O_SYNC; write() will block until the data is on the disk
- - fsync(); flush all in-core buffered data to disk
- - fdatasync(); as fsync(), but don't update inode metadata
> Do the UFS delayed write algorithms kick in here? Does the close()
> force data to be flushed to the file referenced by fd? I can't seem
> to find a definitive answer for this in the close(2) man page,
I don't currently use or have access to Solaris, but this is what the
Linux close(2) man page says:
A successful close does not guarantee that the data has been
successfully saved to disk, as the kernel defers writes. It is not
common for a filesystem to flush the buffers when the stream is
closed. If you need to be sure that the data is physically stored
use fsync(2). (It will depend on the disk hardware at this point.)
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFB5tqGVcFcaSW/ uEgRAiX2AKDfrB6qDKfISlTgt2zhMQIEJicjcQCf
Vt4m
PwgpWm3o23I7rUM0+7T/47A=
=7yi0
-----END PGP SIGNATURE-----
|