On Wed, Jan 23, 2008 at 06:54:41PM +0100, Jan Kara wrote: > A different solution (even with smaller impact) would be to not allow > files with i_size > s_maxbytes in VFS at all. For local filesystems we can > just check this on open and everything is fine
Which we should do. > but with remote filesystems > such as OCFS2 (or NFS) filesize can be changed on the fly from a different > machine. So to avoid problems we can either introduce some locking to > prevent changes of i_size from other machines while we are in critical > sections (awww, I really don't think this is better) or truncate i_size to > s_maxbytes when we update i_size from what we've received via network / > shared storage (but then we'd have to track whether user truncated file to > some size or whether fs truncated it just for safety and apps could be > confused too). So I don't think this is really feasible. The right fix for cluster filesystem is to have a coherent maximum file size for the whole cluster. If that can't be done due to protocol reason we need to lock around i_size update and revoke access to the inode on the client that doesn't support it. Which of course would require a working revoke to start with.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
