Re: Filesystem setattr/truncate notes and problems

[Nick Piggin <npiggin@suse.de>]

On Thu, Jun 03, 2010 at 06:08:55AM +1000, Nick Piggin wrote:
> Interesting specific filesystem questions: (not comprehensive)
> 
> ecryptfs improve mtime/ctime handling for truncate of lower inode
> 
> fuse, should be setting ctime on truncate?
> 
> gfs2, mtime and ctime should only be set in truncate if the ATTR_?TIME
> are set.
> 
> hostfs, don't ignore ATTR_SIZE. ftruncate/truncate have interesting
> different semantics for timestamp updates, so don't use fd != -1 for
> these (could use utimes for this, but it causes an atomicity/error
> handling issue).
> 
> hpfs could use cont_expand to do expanding truncates?
> 
> ncpfs, nfs smbfs, cifs seems to perform inode size checks
> (inode_newsize_ok) after truncating the file on the server??
> 
> ntfs does not do inode size checks properly.
> 
> logfs logfs_truncate without doing inode_change_ok, inode_newsize_ok etc
> can fail inode_setattr after successful truncate (truncate(2) would
> return failure and yet the file would be truncated).
> 
> procfs why not return -EPERM rather than setting size?
> 
> reiserfs should do all setattr checks early as possible
> (inode_change_ok, inode_newsize_ok).
> 
> ubifs should not update access times unconditionally when ATTR_SIZE is
> set
> 
> ufs simple_setsize still destroys the pagecache and causes concurrent
> reads to go EOF past updated i_size. Restoring old i_size is too late
> I think. Should do those checks first (in fairness lots of filesystems
> have bit problems with error handling, but ufs attempts a little bit and
> gets it wrong).
> 
> xfs in the 0 length file shortcut, isn't this missing suid kill case?
> (ftruncate mandatory mtime update seems like it wasn't working right
> there either before this patch).
> 
> nfsd should not change attributes in the case of truncated file with no
> size change?

ceph doesn't seem to call inode_newsize_ok (so it's missing the rlimit
check).