[linux-cifs-client] Re: set last write time = fsync ?

[Jeff Layton]

On Wed, 12 Mar 2008 22:54:50 -0500
"Steve French" <smfrench at gmail.com> wrote:

> kukks noticed that "cp -p source-file /cifs-mnt" would not set the
> last write time to the previous time
> 
> It looks like a straightforward caching sideffect - "cp -p" does
> 
> open
> write
> set time stamps (utimensat)
> set uid/gid (fchown32)
> set acl (setxattr(system.posix_acl_access))
> 
> but the write is cached until close (which does a flush just before
> the close) - so the final write resets the time which was set
> correctly earlier
> 
> Should we add logic to cache the set of the time stamps too (at least
> when there is write behind cache data)?  This would also allow us to
> avoid setting the timestamp in some cases in which a write happened
> after the setattr of the timestamp.
> 
> I don't really want to get to the point where utimes ==> fsync  that
> seems way overdone
> 
> Thoughts?
> 

Interesting -- this seems to be "mtime" week for me. I've been working
on some NFS cache invalidation issues that involve out-of-order mtime
updates...

Actually, this problem looks like a regression caused by the changes
in this patch:

commit cea218054ad277d6c126890213afde07b4eb1602
Author: Jeff Layton <jlayton at redhat.com>
Date:   Tue Nov 20 23:19:03 2007 +0000

    [CIFS] Fix potential data corruption when writing out cached dirty pages


...before that patch we flushed the cache on every setattr call. We now
just do that on size changes, but it sounds like we need to reconsider
this.

Trying to follow Lustre's model sounds tricky and I'm not sure it would
work anyway since the server is going to update the mtime whenever the
write comes in. Consider:

Write --> server sets mtime to current time
Setattr --> server sets mtime for utimes() call
Write --> server resets mtime to current time

...I'm not sure that the client has much control over this. If we don't
want to flush the cache for a setattr, there are two options:

1) delay the setattr until all of the pending writes have been flushed
(tricky and not really what we want)

2) queue up another setattr call after the last write has completed
(also tricky, and possibly problematic)

There could be other problems lurking here too. What happens to the
pending writes when we change the ownership and mode to something where
we no longer have permission to write to the file? I suppose they just
error out and that's not good either.

For the record, NFS seems to flush the cache too on all setattr calls.
From nfs_setattr:

        /* Write all dirty data */
        if (S_ISREG(inode->i_mode)) {
                filemap_write_and_wait(inode->i_mapping);
                nfs_wb_all(inode);
        }

I think we should probably just go back to flushing the cache on
setattr. We could consider not doing it when the attribute change is
something that later writes wouldn't clobber and isn't something that
would prevent later writes from working. That's a pretty narrow set
though...

-- 
Jeff Layton <jlayton at redhat.com>