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=0.6 required=3.0 tests=FORGED_MUA_MOZILLA, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=no 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 1DA74C169C4 for ; Mon, 11 Feb 2019 11:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8C45214DA for ; Mon, 11 Feb 2019 11:25:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726212AbfBKLZJ (ORCPT ); Mon, 11 Feb 2019 06:25:09 -0500 Received: from [195.159.176.226] ([195.159.176.226]:54718 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1726046AbfBKLZJ (ORCPT ); Mon, 11 Feb 2019 06:25:09 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gt9hz-000F6Y-IX for linux-fsdevel@vger.kernel.org; Mon, 11 Feb 2019 12:25:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-fsdevel@vger.kernel.org From: =?UTF-8?Q?Jean-Pierre_Andr=c3=a9?= Subject: Re: [fuse] Relevance of st_ino values Date: Mon, 11 Feb 2019 12:18:06 +0100 Message-ID: References: <875ztrcpkz.fsf@vostro.rath.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 In-Reply-To: <875ztrcpkz.fsf@vostro.rath.org> Cc: fuse-devel@lists.sourceforge.net Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Nikolaus Rath wrote: > Hello, > > For several requests, FUSE userspace returns a struct stat to the > kernel. struct stat includes an st_ino field, but FUSE generally has a > separate field for the inode (e.g. fuse_entry_param.ino vs > fuse_entry_param.attr.st_ino). > > Does the kernel use the st_ino value at all, or is just passed through > to userspace? Fuse defines its own inode number in order to track the path used to access a file. So, when a file is recorded in several directories, it is referenced by fuse with several inode numbers. > > If it is just passed through, is there a need for st_ino to match the > "real" inode? There is no need. Files with several names have a single st_ino value, and a fuse inode value per path met. Unfortunately the inode numbers are used by the kernel to index the caches, and the caches for files with several inode numbers are not kept in sync (long standing issue...). > > Background: > > Given that userspace has no use for inode values other than comparing > them for equality, I would have expected that st_ino can basically be > anything as long as there's some 1:1 mapping to kernel inodes. However, > I have seen changes in userspace behavior when setting st_ino to the > kernel inode (previously it was set to some other value by accident). > > > Thanks! > -Nikolaus >