[lkml]   [2008]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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..

 \ /
  Last update: 2008-01-23 20:15    [W:0.034 / U:8.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site