Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5687464pxj; Wed, 23 Jun 2021 06:59:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzshXfOFiRIimI1Sq93S4AxsDeQK4BRZY4q09VTaurTBuL7dFIBKZydDlk3HCg4pcQzc9Th X-Received: by 2002:a02:cd21:: with SMTP id h1mr9220505jaq.114.1624456742356; Wed, 23 Jun 2021 06:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624456742; cv=none; d=google.com; s=arc-20160816; b=O+23/hWZXLredOlJp0CUlv3fpRLm1zeGLanLMwFGZwb43+Woa0sVQhhyh2ZSfBJ6fP r5j8hB8d2KzTgm7KJ1y8OnmZzQ9x0YoKBKSv64gF0/k25y4jgPE2DZIp0hQNObvuUG/D ksEbnjOgyL/ejIOulCd+2qLxBeggjjmVdz/aORKl87BZDCUGfN/FBaXtInvbx7DlioWL sskESRTjLYcDnoeBYasYm0EeRtEvXDq5xBd6Dz50VR7rAeN19cOV06/ZMdJB+Gp5jX0T 0bWeu7thsmFutDbeKlhqL2knoonfwCTzyqakaeUK4Y+9bj7BZe5x4/KrkHGISSG8kw5y 0Smg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=0iIx71H8/yRkAtQNpe95wCxGWeydv2OxyzFBDk7y+hc=; b=YS3PCW3MBpEnHdvTLgAy2yvsavJOXIfUOIfR8UXFVpKQzwpTkfYValPGlrPaux1uJa K0MkM+DPMbP/DDmvryJZTf8okyQSqTvU9DW/J5sKfHwHuSGlrhisETH/uyoFqEWnPbkx YZ7cyw18oBfIh6W+nLlgoqhXikL93fbpGCGand3TVGJh/qDEHhfYE/lOPzhXmZWGWa71 SHjzGpfdloGWFftLHIiolP/c3qVGX2mgsTgxhHi3apSG3kPBX3W4ljnvo8irUmrtI2Fe YZO+N2vURiV4jjLPFpddBCCeYODKMC4G/yIYuIk/HvaOa8PCJM1uzS11kBZf99nKka8s i9lg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t8si18139426ilu.89.2021.06.23.06.58.49; Wed, 23 Jun 2021 06:59:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbhFWOAb (ORCPT + 99 others); Wed, 23 Jun 2021 10:00:31 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:53724 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230263AbhFWOAa (ORCPT ); Wed, 23 Jun 2021 10:00:30 -0400 X-Greylist: delayed 414 seconds by postgrey-1.27 at vger.kernel.org; Wed, 23 Jun 2021 10:00:30 EDT Received: from gardel-login.0pointer.net (gardel-mail [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 3DC0EE8094B; Wed, 23 Jun 2021 15:51:12 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id EEA28160DC0; Wed, 23 Jun 2021 15:51:11 +0200 (CEST) Date: Wed, 23 Jun 2021 15:51:11 +0200 From: Lennart Poettering To: Matteo Croce Cc: Christoph Hellwig , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jens Axboe , Linux Kernel Mailing List , Luca Boccassi , Alexander Viro , Damien Le Moal , Tejun Heo , Javier Gonz??lez , Niklas Cassel , Johannes Thumshirn , Hannes Reinecke , Matthew Wilcox , JeffleXu Subject: Re: [PATCH v3 1/6] block: add disk sequence number Message-ID: References: <20210623105858.6978-1-mcroce@linux.microsoft.com> <20210623105858.6978-2-mcroce@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mi, 23.06.21 15:10, Matteo Croce (mcroce@linux.microsoft.com) wrote: > On Wed, Jun 23, 2021 at 1:49 PM Christoph Hellwig wrote: > > > > On Wed, Jun 23, 2021 at 12:58:53PM +0200, Matteo Croce wrote: > > > +void inc_diskseq(struct gendisk *disk) > > > +{ > > > + static atomic64_t diskseq; > > > > Please don't hide file scope variables in functions. > > > > I just didn't want to clobber that file namespace, as that is the only > point where it's used. > > > Can you explain a little more why we need a global sequence count vs > > a per-disk one here? > > The point of the whole series is to have an unique sequence number for > all the disks. > Events can arrive to the userspace delayed or out-of-order, so this > helps to correlate events to the disk. > It might seem strange, but there isn't a way to do this yet, so I come > up with a global, monotonically incrementing number. To extend on this and given an example why the *global* sequence number matters: Consider you plug in a USB storage key, and it gets named /dev/sda. You unplug it, the kernel structures for that device all disappear. Then you plug in a different USB storage key, and since it's the only one it will too be called /dev/sda. With the global sequence number we can still distinguish these two devices even though otherwise they can look pretty much identical. If we had per-device counters then this would fall flat because the counter would be flushed out when the device disappears and when a device reappears under the same generic name we couldn't assign it a different sequence number than before. Thus: a global instead of local sequence number counter is absolutely *key* for the problem this is supposed to solve Lennart -- Lennart Poettering, Berlin