Date: Wed, 23 Jan 2008 19:13:06 +0000
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
       Mark Fasheh <mark.fasheh@oracle.com>
Subject: Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly
Message-ID: <20080123191306.GA17118@infradead.org>
References: <20080123175440.GF10144@duck.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080123175440.GF10144@duck.suse.cz>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1456
Lines: 28

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