Hi,
On Mon, 19 Jul 1999 20:08:13 +0200, "Lennert Buytenhek" <[EMAIL PROTECTED]> said:
> Hi all,
> Hoping you all might be able to learn me something, I ask you:
> 2. Is fsync() supposed to sync all outstanding writes for that file
> handle only, or for the inode that is referenced by it?
>From SingleUnix:
The fsync() function can be used by an application to indicate that
all data for the open file description named by fildes is to be
transferred to the storage device associated with the file described
by fildes in an implementation-dependent manner. The fsync()
function does not return until the system has completed that action
or until an error is detected.
So it should flush for all file handles.
> In linux, for example, nfs syncs only the file, ext2 syncs the
> inode. Syncing the file only is probably more logical, but dirty
> buffers are hard to distinguish I guess.
According to the specs, that looks like an NFS bug. However, NFS does
not quite follow standard Unix filesystem semantics 100% anyway, so this
might actually be compatible with other NFS implementations. Anyone
know?
> 3. Why does the fsync() file operation have a dentry argument?
History. :)
> 4. [offtopic?] Why does the ioctl() file operation have an inode
> argument?
Same answer?
> 5. I was doing fdatasync() yesterday (currently it does the same as
> fsync(), I'm trying to fix that) when I had the following thoughts:
I already have fdatasync diffs for 2.2, I'll try to merge into 2.3 at
some point.
> 1. fdatasync() only syncs the data, not the metadata
It should sync both. The only exception is that fdatasync is not
required to sync timestamp updates.
> 2. So, it would likely be correct not to sync the inode itself on a
> fdatasync()
No.
> 3. Unfortunately, if a file has grown the inode must be updated to
> reflect this.
And if permissions have changed, or indirect blocks have changed, or
ownership or anything else has changed, it must be synced.
> 4. So even fdatasync() might need to sync the metadata sometimes.
> 5. But fdatasync() never needs to sync the superblock.
Yes.
> So, summarising:
> 1. superblocks:
> 2. bitmaps:
These never need to be synced. All dynamic data in the superblock or
bitmaps can be recovered by e2fsck after an unplanned reboot.
> 3. inode table:
> fsync(): yes ?
> fdatasync(): only when something other than the time was
> changed?
Yes.
> 4. data blocks (including indirect blocks):
> fsync(): yes
> fdatasync(): yes
Exactly.
> 6. I was planning on doing fdatasync by something like:
> int (*fsync)(struct file *filp, int sync_metadata); or
> int (*fsync)(struct file *filp, int full_fsync); or
> int (*fsync)(struct file *filp, int sync_all);
I've done it by splitting the inode dirty flag into two separate bits,
one for fdatasync inode dirty state (ie. excluding timestamps) and one
which includes timestamp dirty state too. And yes, I had to add a
fdatasync argument to the VFS fsync() method.
--Stephen
