Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3606947ybv; Tue, 25 Feb 2020 04:15:29 -0800 (PST) X-Google-Smtp-Source: APXvYqzlN4m8kQkX8p8TT2g9wNb2+4YSk7SkaSqEwTv2XQdTUg8fp1O9dpXFuQ6dWs3GS1+QsozM X-Received: by 2002:a05:6830:128e:: with SMTP id z14mr38833119otp.184.1582632929383; Tue, 25 Feb 2020 04:15:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582632929; cv=none; d=google.com; s=arc-20160816; b=XVhxJqN8DXpZWq8mAtX0vleQjFGu3Cc8q6n8hAPa+tN8C8iCIWkteJWVEMysOj3hzl 8trOyjaxhxOVAP+/QqoqdUKzhf6upsObF9w7KUVLsdK0TCX17Gi5AKfQekx3lZbYFfcD 2zinjiyIG7oR2hxLOXh3LShCOxEFh+ZR5l+g4Xg/aSBsbk3BgKqgNluXpxSqy514Usek QI1LlEYlj4zUQFvjcRXkmSVpRa1BaOKK2O5ChW5i3OVDOl5EvobE373UoF2sIc9PbM73 gTpn+m1mRTgO1IFfx+Xr/cqGLXFseyTL+Ljl7fkyKQOGEozhH+KDaxU+Vydo5FtrFUJA x59A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=+wrw7WE/m40W3sxI/uRBNf21Q8ICUq5UNJSWodR4eJA=; b=Dw2cAYv9k3UfvgdVD1Vg9PrPYAX7sKl6PSY64eFL3VmBHNq//ESxiokYXg1YxvIVKc 6xYWWRNq+nkK9VozFdHAuDOhMr1huS7onZ0CIQLmLWtqt08YPo0KapUG5d9Gp6FscDMx D5OgSRfgz6M3HoES5llsJS8Xe2yuy4hL0a6nx+8uuwd5q3PbUNKKRVuBDx53VeyW92T6 zoGy8bpfQ3iOjVwUqzi3wS9wWwuO6o+z21sgO4UJShw7GGfwOBFCZ68Xex4J6WX2Jfzr ZvHKddUQkms2PYltnzrROMcBKAfey+ZN93m/DHZcgbgE0s8llWrWW5XbaSQEPnxcGt9s 9IdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CI6CtbwD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i2si5319307oie.181.2020.02.25.04.15.17; Tue, 25 Feb 2020 04:15:29 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CI6CtbwD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729221AbgBYMNV (ORCPT + 99 others); Tue, 25 Feb 2020 07:13:21 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:32301 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725788AbgBYMNV (ORCPT ); Tue, 25 Feb 2020 07:13:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582632800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+wrw7WE/m40W3sxI/uRBNf21Q8ICUq5UNJSWodR4eJA=; b=CI6CtbwDFBX/4mmlMm2leM9gTkc01bKsqLStrZJrwsV3hFpXAgZMca58eWG5j3Spvq3ceS FNmgIl/kQ/U9eCdo59k+4w08hhaQY1Pwfy6nGdtMS8fH5y9Mx3Fh2AeBgTuPxdyO4GqgmZ 6VmFRABNxS/dx8IPeMshtYqI0/CAVgE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-J14YSICYPv2YWiUP_29jHA-1; Tue, 25 Feb 2020 07:13:18 -0500 X-MC-Unique: J14YSICYPv2YWiUP_29jHA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A0FBC8017CC; Tue, 25 Feb 2020 12:13:16 +0000 (UTC) Received: from fogou.chygwyn.com (unknown [10.33.36.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CF7027186; Tue, 25 Feb 2020 12:13:13 +0000 (UTC) Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: Miklos Szeredi , James Bottomley Cc: Miklos Szeredi , David Howells , viro , Ian Kent , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml References: <158230810644.2185128.16726948836367716086.stgit@warthog.procyon.org.uk> <1582316494.3376.45.camel@HansenPartnership.com> <1582556135.3384.4.camel@HansenPartnership.com> From: Steven Whitehouse Message-ID: Date: Tue, 25 Feb 2020 12:13:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 24/02/2020 15:28, Miklos Szeredi wrote: > On Mon, Feb 24, 2020 at 3:55 PM James Bottomley > wrote: > >> Once it's table driven, certainly a sysfs directory becomes possible. >> The problem with ST_DEV is filesystems like btrfs and xfs that may have >> multiple devices. > For XFS there's always a single sb->s_dev though, that's what st_dev > will be set to on all files. > > Btrfs subvolume is sort of a lightweight superblock, so basically all > such st_dev's are aliases of the same master superblock. So lookup of > all subvolume st_dev's could result in referencing the same underlying > struct super_block (just like /proc/$PID will reference the same > underlying task group regardless of which of the task group member's > PID is used). > > Having this info in sysfs would spare us a number of issues that a set > of new syscalls would bring. The question is, would that be enough, > or is there a reason that sysfs can't be used to present the various > filesystem related information that fsinfo is supposed to present? > > Thanks, > Miklos > We need a unique id for superblocks anyway. I had wondered about using s_dev some time back, but for the reasons mentioned earlier in this thread I think it might just land up being confusing and difficult to manage. While fake s_devs are created for sbs that don't have a device, I can't help thinking that something closer to ifindex, but for superblocks, is needed here. That would avoid the issue of which device number to use. In fact we need that anyway for the notifications, since without that there is a race that can lead to missing remounts of the same device, in case a umount/mount pair is missed due to an overrun, and then fsinfo returns the same device as before, with potentially the same mount options too. So I think a unique id for a superblock is a generically useful feature, which would also allow for sensible sysfs directory naming, if required, Steve.