Re: why does fsync() on a tmpfs directory give EINVAL?

[Hugh Dickins <hugh@veritas.com>]

On Thu, 16 Jun 2005, Andrew Morton wrote:
> Chris Friesen <cfriesen@nortel.com> wrote:
> > Andrew Morton wrote:
> > > Chris Friesen <cfriesen@nortel.com> wrote:
> > >>Currently tmpfs reuses the simple_dir_operations from libfs.c.
> > >>
> > >>Would it make sense to add the empty fsync() function there, and have 
> > >>all other users pick it up as well?  Is this likely to break stuff?
> > >  
> > > Isn't simple_sync_file() suitable?

Yes.

> > Alternately, if it makes sense for all the users of 
> > simple_dir_operations we could modify it directly and all of the other 
> > users of simple_dir_operations would get the change for free.  I don't 
> > know enough about the other filesystems to know if this makes sense or not.

That makes the best sense, yes.

> hm, what a lot of filesystems.
> ..... 
> I can't think of any reason why any of these would want fsync(dir_fd) to
> return -EINVAL.

No need to check the list: any filesystem using simple_dir_operations
is using dcache_readdir, which implies there's no storage to be synced.
And we all agree that success is a more helpful retval than -EINVAL
when there's nothing for fsync to do.  Here's a patch if you haven't
done it already....

tmpfs, and all other users of simple_dir_operations, should return 0
to say directory fsync was successful, instead of the worrying -EINVAL.

Signed-off-by: Hugh Dickins <hugh@veritas.com>

--- 2.6.12-rc6-git8/fs/libfs.c	2005-03-02 07:38:44.000000000 +0000
+++ linux/fs/libfs.c	2005-06-17 14:16:29.000000000 +0100
@@ -183,6 +183,7 @@ struct file_operations simple_dir_operat
 	.llseek		= dcache_dir_lseek,
 	.read		= generic_read_dir,
 	.readdir	= dcache_readdir,
+	.fsync		= simple_sync_file,
 };
 
 struct inode_operations simple_dir_inode_operations = {