From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D70BC282C3 for ; Thu, 24 Jan 2019 14:53:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E92D9218CD for ; Thu, 24 Jan 2019 14:53:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728445AbfAXOxW (ORCPT ); Thu, 24 Jan 2019 09:53:22 -0500 Received: from nautica.notk.org ([91.121.71.147]:53058 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728366AbfAXOxW (ORCPT ); Thu, 24 Jan 2019 09:53:22 -0500 Received: by nautica.notk.org (Postfix, from userid 1001) id B1300C009; Thu, 24 Jan 2019 15:53:19 +0100 (CET) Date: Thu, 24 Jan 2019 15:53:04 +0100 From: Dominique Martinet To: Hou Tao Cc: v9fs-developer@lists.sourceforge.net, lucho@ionkov.net, ericvh@gmail.com, linux-fsdevel@vger.kernel.org, xingaopeng@huawei.com Subject: Re: [PATCH v3 2/2] 9p: use i_lock to protect update of inode->i_blocks under 32-bit Message-ID: <20190124145304.GA8716@nautica> References: <20190124063514.8571-1-houtao1@huawei.com> <20190124063514.8571-3-houtao1@huawei.com> <20190124072532.GA16424@nautica> <20190124144539.GA1457@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190124144539.GA1457@nautica> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Dominique Martinet wrote on Thu, Jan 24, 2019: > > > - if I create a file outside of 9p and stat it, for example starting > > > with 400 bytes, it starts with 8 blocks then the number of blocks > > > increase by 1 everytime 512 bytes are written regardless of initial > > > size. > > > > The initial i_blocks comes from the underlying filesystem, so I think 8 blocks > > just mean the block size of the underlying filesystem is 4KB. If another 512 bytes > > are written into the file, inode_add_bytes() will increase i_blocks by one instead of > > fetching i_blocks from server, though i_blocks in server side will > > still be 8. > > Ah, I had only looked at v9fs_stat2inode() which creates the value from > i_size, not v9fs_stat2inode_dotl(). > v9fs_stat2inode_dotl() does take the value from the RPC, and then 8 is > indeed correct -- it will just be very painful to keep synchronized with > the underlying fs; we have no ways of knowing when the remote filesystem > decides to allocate new blocks. > If for example the write iter only writes 0 and the underlying fs is > optimized st_blocks might not increase at all. > > > Maybe we should call v9fs_invalidate_inode_attr() in v9fs_write_end() ? > > Hmm, That will probably add quite a lot of RPCs and make the cache > option rather useless... Actually I made an interesting point without realizing it myself - thinking back of the option, I would keep the current behaviour with cache=none/mmap (as the inode attr will be invalid and refreshed on every stat anyway - this incidentally probably is why I never noticed it, cache=none works just fine as far as st_blocks is concerned because it always returns the underlying storage's block count) and just 100% fake it for cache=fscache/loose. Still going to bring this whole subject up in a separate thread to fsdevel tomorrow, I'll put you and the v9fs-developer list in cc. Will also add a note to run more testings with various cache options... -- Dominique