> Currently touch_atime and file_update_time directly update a/c/mtime > in the inode and just mark the inode dirty afterwards. This is pretty > bad for some more complex filesystems that have various different types > of dirtying an inode and/or need to store the data in another place > for example for a buffer to be logged. > > This patch changes touch_atime and file_update_time to not update the > inode directly but rather call through ->setattr into the filessystem. Do we know what effect this will have on read/write performance? I can imagine that some ->setattr() implementations are orders of magnitude slower than just dirtying the inode. > There is a new ATTR_UPDTIMES flag for these two calls so filesystems > know it's just a timestampts update. This allows some optimizations > and also allow to kill the IS_NOCMTIME we curretly have for networked > filesystem by letting them simpliy ignore these kind of updates. > > There is also a new ATTR_VERSION flag sent from file_update_time > that tells the filesystem to update i_version because this update > has the same issues as the timestamp updates. > > As a side-effect of the optimiation to not perfrom redundant timestamp > updates has been moved from touch_atime and file_update_time to > notify_change and thus applies to explicit utimes calls, too. This optimization is fishy. Remember, inode->i_*time are just cached values, and the actual times on the (remote) filesystem itself can differ. Which means that we will now optimize out a "touch" because we happened to have the current time cached in the inode. Not that this would be a likely event, but still... So at least this check should be made dependent on ATTR_UPDTIMES, and explicit time updates left alone. Miklos -- 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
