Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/patches/fsync.README
2024-02-19 00:24:15 -05:00

58 lines
2.4 KiB
Plaintext

These are the kernel patches for the "fsync" system call for Linux.
You will need at least 0.99pl7A (0.99pl7 + ALPHA-diffs) to run them.
There have been many changes to the Linux filesystems recently, but
things now seem stable enough to release the fsync code.
Apply the patches with "patch -p0<fsync.99pl7A.cd.z" from the
directory containing the linux source tree (eg /usr/src). The "-p0"
flag is important - it is required to ensure that the various new
fsync.c files get created in the correct directories.
int fsync(int fd) is a system call which ensures that a file's data is
flushed onto physical media. It makes sure that all the data
associated with the file on disk is up to date.
There is special code to handle fsync() of files for the ext, ext2,
minix and xiafs file systems. There is also generic code to handle
fsync of complete block devices. Currently, for file systems which
lack special support (such as the MSDOS fs), fsync() still works but
syncs the entire device rather than just the given file.
fsync() returns the following error messages:
0 Success.
-1 Error; errno is one of:
EBADF Bad file descriptor
EINVAL fsync() not supported - for example, fs is a socket or FIFO
EIO An IO error occurred during the fsync().
fsync() on a block device special file will sync all dirty blocks on
that device. fsync() on a directory will also sync that entire file
system (but only for that single mounted device - it does not do a
full sync of all devices).
Note that whereas sync(2) just requests disk IO and can return before
the IO is complete, fsync(2) WILL NOT return until all IO has
completed (successfully or not).
Fsync is currently the ONLY way in which an application can detect a
kernel write failure when it occurs. It is not guaranteed to detect
all failures; write errors are associated with individual buffers in
the buffer cache, and if fsync() is called sufficiently past the write
failure, it is possible that the failed buffer may have been flushed
from the buffer cache. I am considering adding an O_SYNC option to
open(2) for block devices to overcome this problem.
Until fsync() gets included in the Linux libraries, you will have to
define it yourself in any programs using it, with
#include <linux/unistd.h>
_syscall1(int,fsync,int,fd)
This code will be compatible with earlier kernels; the call to fsync
will return ENOSYS (call not implemented) if the binary is run on a
kernel without fsync.
Regards,
Stephen Tweedie <sct@dcs.ed.ac.uk>