[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.020 / U:18.992 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site