[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1842058.1646865301@warthog.procyon.org.uk>
Date: Wed, 09 Mar 2022 22:35:01 +0000
From: David Howells <dhowells@...hat.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: dhowells@...hat.com, linux-cachefs@...hat.com,
linux-afs@...ts.infradead.org,
Anna Schumaker <anna.schumaker@...app.com>,
Steve French <sfrench@...ba.org>,
Dominique Martinet <asmadeus@...ewreck.org>,
David Wysochanski <dwysocha@...hat.com>,
Ilya Dryomov <idryomov@...il.com>,
Jeffle Xu <jefflexu@...ux.alibaba.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
ceph-devel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 19/19] afs: Maintain netfs_i_context::remote_i_size
Jeff Layton <jlayton@...nel.org> wrote:
> > - op->store.i_size = max(pos + size, i_size);
> > + op->store.i_size = max(pos + size, ictx->remote_i_size);
>
> Ahh ok, so if i_size is larger than is represented by this write, you'll
> have a zeroed out region until writeback catches up. Makes sense.
That's the way it was working. With this change, we track the server's idea
of the file size separately from our local inode->i_size (which is updated by
the modifications into the pagecache) and only expand the server's setting to
the end of the data we're storing, not to our local i_size. I'm trying to
avoid zeroed-out regions appearing in the file.
Forcible expansion by truncate is a different matter.
David
Powered by blists - more mailing lists