Messages in this thread | | | Date | Wed, 23 Jan 2008 19:13:06 +0000 | From | Christoph Hellwig <> | Subject | Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly |
| |
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..
| |