Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly

[Mark Fasheh]

This reply comes a bit late, sorry about that.

On Wed, Jan 23, 2008 at 07:13:06PM +0000, Christoph Hellwig wrote:
> > 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

Yeah, as you noted, there's problems with that approach. The first is that
we don't control when a 32 bit node mounts the file system. Communicating it
over the network wouldn't help because information communicated over the
network is transient and will be lost when all nodes unmount, whereas
maximun i_size for a volume is the type of thing which needs to be
permanent. Putting a "max i_size" field in the superblock is one way to
ensure that we never get into this situation but that would leave existing
file systems without a fix.


> 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..

If we had a way to disable access to an inodes data, Ocfs2 could mark the
inode when it takes a cluster lock and discovers that i_size grew past what
the local node can handle.
	--Mark

--
Mark Fasheh
Principal Software Developer, Oracle
mark.fasheh@xxxxxxxxxx
--
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/