Received: by 10.223.164.202 with SMTP id h10csp6256130wrb; Wed, 22 Nov 2017 01:33:57 -0800 (PST) X-Google-Smtp-Source: AGs4zMbPDohfW63EnCXZSv/9UvUqco1ii26Y9DMVyh3eZCLR14wA7mU9Zb4A5gaisttBXhLandIe X-Received: by 10.84.224.206 with SMTP id k14mr20803793pln.403.1511343237664; Wed, 22 Nov 2017 01:33:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511343237; cv=none; d=google.com; s=arc-20160816; b=zU2o6lT/HVrJO8lPeDa44dICdWwKHJ6u/ZMIl42+47U0DnLkOp1rimZqyqK7cK4Ps3 kSf0J+LKYZTIeoSFVdNZ2ismACt5sQU2AWo+67iTJLCMh0qn4zIIGmmGgdNvgbTYzArA rE8YQ8Ruy3NuVqxJVuf0sLC8p6p7Txp9MLvgBzzZyIEzYTfz8odgjE8BcJW0Sre1dlyd y8535A5cOED76vyZeXtjJ0pi1/D/oelLMhIZiT1CStbG0j5rP9AqanJOfRaX3CIKMKoZ 5mlyY3ExNohhZWiBHxZzs7xC2ZTqHMVOftHAVQvoQMc2LwM2o+ByJIo+cgjsUWJ0AXJG wGPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:date:message-id:cc:to:subject:from :arc-authentication-results; bh=TEl0iY/5r6OoUQYkensb+yJ6//cIB5ZG7yUcFJf1UY8=; b=O+8WPFqLynb+Fj5DlIm36H/8EwdzxGGQw7mRl8hYODim+2RnPli4qeQ8YllJciGwiK 316/jpaOJkTkPevlWYHUIJXBCqG7RcInSJ0TtE1xm7YTzEzjGvMQH3m4RLF1/tAB6GQl vO7ylSGDmYc+VsgUPbo/ihEU6/E8PpUpxjRMeRJ2CPsQNQ+6SgIGrmruyBSdlWUJelFv nMRMeNMsf8OanJjDrXQ8+YP9o2Qt7T+C8xbi88oSDRhHmXeEeg5NzDamPbkA+sLNQav1 AmsFwV8sC2Y7ltE1eqGtrFPQKKkj8dkAvAYrM15OT3TOVi/xXyy4h+BT+MiipLTVpaN0 e1cQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 78si11254766pfq.361.2017.11.22.01.33.46; Wed, 22 Nov 2017 01:33:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751934AbdKVJcX (ORCPT + 75 others); Wed, 22 Nov 2017 04:32:23 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:56378 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751273AbdKVJcV (ORCPT ); Wed, 22 Nov 2017 04:32:21 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 56FC7FA7E1BAD; Wed, 22 Nov 2017 17:32:07 +0800 (CST) Received: from [127.0.0.1] (10.177.16.168) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.361.1; Wed, 22 Nov 2017 17:31:11 +0800 From: jiangyiwen Subject: [V9fs-developer] [bug report] fs/9p: inode blocks show error in fscache mode To: Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , CC: , , , Eduard Shishkin , "Xulei (Stone)" Message-ID: <5A1543DA.30504@huawei.com> Date: Wed, 22 Nov 2017 17:31:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.16.168] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, I test a scenario that will cause the difference of inode blocks between client and host, the scenario as follows: Precondition: 1) use VirtFS(virtio-9p) to connect guest and host. 2) 9p dir in guest is /mnt/9p, host is /9p-host. 3) server fs is ext4 and block size is 4096. Test steps: 1) on the client(guest) # touch /mnt/9p/test/file # dd if=/dev/zero of=/mnt/9p/test/file bs=1 count=1043456 seek=1302528 conv=notrunc 2) on the client(guest) # stat /mnt/9p/test/file the file's blocks is 4582 blocks(block size is 512) 3) on the server(host) # stat /9p-host/test/file the file's blocks is 2040 blocks(block size is 512) Cause analysis: Because the file is sparse file, so in function v9fs_write_end will update inode blocks according to difference between last_pos and inode_size, only when last_pos is larger than the inode_size, then it update the blocks and inode_size, the operation is not fit the sparse file. Currently I want to call v9fs_invalidate_inode_attr to invalidate inode, but it will influence the performance, so I don't have a good solution. Please advise. Thanks in advance! Best regards, Yiwen From 1584733870607596541@xxx Wed Nov 22 03:06:30 +0000 2017 X-GM-THRID: 1584732609630067587 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread