Re: [PATCH ] Fix some problems with truncate and mtime semantics.

[Neil Brown <neilb@suse.de>]

On Tuesday November 15, miklos@szeredi.hu wrote:
> > Finally, if vmtruncate succeeds, and ATTR_SIZE is the only change
> > requested, we now fall-through and mark_inode_dirty.  If a filesystem
> > did not have a ->truncate function, then vmtruncate will have changed
> > i_size, without marking the inode as 'dirty', and I think this is wrong.
> 
> And if filesystem does not have a ->truncate() function and it caller
> was [f]truncate(), ctime and mtime won't be set.
> 
> That's wrong too, isn't it?

I don't think that is a problem.  
The filesystem would have had a ->setattr function which would have
been told that the size had changed, and it would have had to change
the inode, and so would have updated the ctime and probably mtime.

Changing i_size without marking the inode dirty is an issue of
consistency of common data structures and inode_setattr should be
careful about that.

Changing ctime/mtime when the isize changes is an issue of filesystem
correctness, and the filesystem callbacks should handle that.

Changing mtime when isize DOESN'T change is an issue of obscure
POSIX/SUS semantics.  It was less clear where this should be handled.
I think the handle of this is now better.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/