lkml.org 
[lkml]   [2008]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] fsstack: fsstack_copy_inode_size locking
    In message <Pine.LNX.4.64.0806291244440.32708@blonde.site>, Hugh Dickins writes:
    > On Sun, 29 Jun 2008, Christoph Hellwig wrote:
    > >
    > > Btw, I hope fsstack doesn't rely on i_size having any particular
    > > meaning. As far as the VFS is concerned i_size is field only used by
    > > the filesystem (or library routines like generic_file_*).
    >
    > Interesting point. I can't speak for fsstack itself (I'm not even
    > sure if it's anything beyond fs/stack.c and the tag I used to identify
    > where this patch lies); but certainly fs/stack.c doesn't use i_size
    > for anything, just duplicates it from the lower filesystem.
    >
    > unionfs (which I think you don't care for at all in general) does
    > look as if it assumes it's the lower file size in a few places,
    > when copying up or truncating. Isn't that reasonable? Wouldn't
    > users make the same assumption?
    >
    > Or are you saying that filesystems which don't support the usual
    > meaning of inode->i_size (leave it 0?) would supply their own
    > equivalent to vmtruncate() if they support truncation, and their
    > own getattr which fills in stat->size from somewhere else.
    >
    > Yes, I think you are saying that: unionfs may not play well with them.
    >
    > Hugh

    Hugh, yes, the only place in fsstack where i_size is used is to copy the
    lower i_size to the upper one verbatim. If this assumption is incorrect for
    some lower file systems, then stackable file systems in general may have a
    problem with this assumption; in that case, we'll need an alternative way to
    "interpret" the lower i_size, and report the i_size in the upper inode (and
    hence to the user).

    Is there such an alternative?

    BTW, ecryptfs may have a problem with this, b/c it uses i_size_read/write
    b/t the lower and upper inodes. If some filesystems have a different
    interpretation for i_size, then stacking ecryptfs on top of them could be an
    issue. Mike?

    Erez.


    \
     
     \ /
      Last update: 2008-06-30 20:25    [W:6.169 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site