Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly

[Jan Kara <jack@suse.cz>]

On Wed 23-01-08 19:13:06, Christoph Hellwig wrote:
> 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.
  I'm fine with that ;).

> > 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..
  But with which lock you'd like to lock-around i_size update? Note that
you have to make sure you won't race even with read path which currently
doesn't take any locks at all (except for page lock) if I'm right... So,
e.g. NFS, would have to wrap generic_file_aio_read() in some lock to
prevent inode updates while generic_file_aio_read() runs. That doesn't
sound too appealing to me.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR