On Wed, Jun 09, 2010 at 12:07:15PM +0200, Christoph Hellwig wrote: > On Wed, Jun 09, 2010 at 11:41:21AM +0200, Jan Kara wrote: > > That's a good point. For all local filesystems I know, holding i_mutex is > > enough for having stable i_size. But for clustered filesystems it > > definitely isn't. They have to hold cluster locks to be able to reliably > > check current i_size (at least OCFS2 does). Looking at what > > inode_newsize_ok currently does, i_size is only used to decide whether > > we need to check for rlimit or not. So we could falsely miss this > > check (other node is truncating the file below new offset)... Hmm, OK, so > > we really need the cluster lock... > > BTW: Mark, don't we need the cluster lock also for the permission > > checks in inode_change_ok? Otherwise we could see: > > Yes, we should have it for all of the checks. It would be good if > the cluster folks came up with proper patches for vfs.git #for-next > to fix up the cluster locking for all of ->setattr. What about network filesystems? Some (ceph, cifs) seem to do i_size checks under i_lock. Pseudo filesystems -- most seem OK. Miklos why do you time out the attributes on inodes? Is this accounted for when doing setattr checks (ie. might any attributes be stale here?) And what to do about intermediate breakage in vfs tree? Should we instead add a new helper which does all the required checks and then push non obvious changes through filesystem trees? -- 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
