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). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
