On Thu, Jun 10, 2010 at 08:09:36PM +0800, Tao Ma wrote: > Joel Becker wrote: > >On Thu, Jun 10, 2010 at 10:27:11AM +0200, Christoph Hellwig wrote: > >>You just leave the duplicate inode_newsize_ok in, but still have > >>one as part of inode_change_ok. See the previous thread - we'll > >>need to move inode_change_ok to under the cluster locks, both > >>for the truncate and non-truncate case. > > > > Is your concern that the u/gid checks may be against stale ids? > So I think we should have one inode_change_ok before the cluster > lock and another after the cluster lock. > The first one will save us a lot of cluster lock effort if the user > pass us the wrong arguments while the later > one will test again with the refreshed inode info. If attributes cannot be stale, then do the checks before the cluster lock and not again. If they can be stale, then the check outside the cluster lock might give incorrect results so it is not harmless to do it twice. If you have a mix of some attributes may be stale, then why not do the inode_change_ok check inside the lock, and then do some open code checks for optimization before taking the lock. -- 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
