kern/64875: Add a system call: fdatasync()

[David Schultz]

The following reply was made to PR kern/64875; it has been noted by GNATS.

From: David Schultz <das at FreeBSD.ORG>
To: Kevin Lo <kevlo at FreeBSD.ORG>
Cc: freebsd-gnats-submit at FreeBSD.ORG, alc at FreeBSD.ORG
Subject: Re: kern/64875: Add a system call: fdatasync()
Date: Tue, 19 Apr 2005 00:07:48 -0400

 On Sun, Mar 28, 2004, Kevin Lo wrote:
 > >Number:         64875
 > >Category:       kern
 > >Synopsis:       Add a system call: fdatasync()
 [...]
 > >Description:
 > fdatasync()is part of realtime extensions in POSIX 1003.1.
 > 
 > DESCRIPTION
 >      The fdatasync() function forces  all  currently  queued  I/O
 >      operations  associated  with  the  file  indicated  by  file
 >      descriptor fildes to the synchronized I/O completion state.
 [...]
 > +int
 > +fdatasync(td, uap)
 > +	struct thread *td;
 > +	struct fsync_args /* {
 > +		int fd;
 > +	} */ *uap;
 > +{
 > +	struct vnode *vp;
 > +	struct file *fp;
 > +	vm_object_t obj;
 > +	int error;
 > +
 > +	GIANT_REQUIRED;
 > +
 > +	if ((error = getvnode(td->td_proc->p_fd, uap->fd, &fp)) != 0)
 > +		return (error);
 > +	if ((fp->f_flag & FWRITE) == 0) {
 > +		fdrop(fp, td);
 > +		return (EBADF);
 > +	}
 > +	vp = fp->f_vnode;
 > +	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
 > +	if (VOP_GETVOBJECT(vp, &obj) == 0) {
 > +		VM_OBJECT_LOCK(obj);
 > +		vm_object_page_clean(obj, 0, 0, 0);
 > +		VM_OBJECT_UNLOCK(obj);
 > +	}
 > +	error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, td);
 > +	VOP_UNLOCK(vp, 0, td);
 > +	fdrop(fp, td);
 > +	return (error);
 > +}
 
 This is a good start, but there are several problems with the patch.
 
 - The above is basically the same as fsync().  The whole point of
   fdatasync() is to be more efficient than fsync() by not syncing
   the file metadata, so it's misleading to implement it as an alias
   for fsync().  I think a correct implementation could be achieved
   by omitting the VOP_FSYNC() call and passing the OBJPC_SYNC flag
   to vm_object_page_clean(), but Alan should review this.
 
   - Regarding the above, what's supposed to happen if the file size
     changes, or if the file was recently created, and its inode has
     not been written at all yet?  I'm not sure whether fdatasync()
     is supposed to omit all metadata updates or just `unimportant'
     ones like atime and mtime.  If my suggestion above isn't
     adequate, the VOP_FSYNC() interface may need to be extended.
 
 - The proposed documentation for fdatasync() needs to be rewritten,
   for two reasons.  First, although we do have permission to copy
   text from POSIX, it's still plagiarism to do so without
   acknowledgement.  Second, the POSIX documentation is not very
   helpful in this case; what's the ``synchronized I/O completion
   state'' anyway?