Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly

[Christoph Hellwig]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/