Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5692230pxj; Wed, 23 Jun 2021 07:04:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLmNhcm2E4LU8wA4m1IBR3d759Ak0QyYKjvimxl0qTRRnww9L+gYXerFB51z5gyI7bdN7A X-Received: by 2002:a05:6e02:1748:: with SMTP id y8mr3217584ill.234.1624457050739; Wed, 23 Jun 2021 07:04:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624457050; cv=none; d=google.com; s=arc-20160816; b=HyaqXgoyUKYwtAS61c8xDDJdR4w2UV3m3yzezC2f6m6GJP/5R9m8r1YbG5GvzXgsna OhyWr/iHW2G4URYPWdqfr1lRRlqV0TkHvL7HFYu+JndheZXhcTSJEje+1B14LzvO26Nm nWMEry0sSXcOPg4rs93f/nP1Y5m5LKVlfltABFX6KaaiT1FV22m05Cb/ayjq4uoNdaDt Dp0JD4fYXqMiz6H/Ui5/3eUPpNKvlEKQ/hCwRAJjPuvG/ufJlPxvEE0Nbe3KC6mCfg3R Ssb2pRsrHAbzfY7q7tdybGFXEZXlLxL0E304ZCCiNNPkWug9GR5n7K9Unyq9v/diHChv Ov3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature:dkim-signature:dkim-signature :dkim-signature; bh=w/XMjSd1ArDZiIdvvGl7Gc1Zip3z1VcHSbThBZcRsbU=; b=dq7q0Lf7Nk7hpaUKING3/h0FoqaV5dtR75SEYq9SE2V5knKOGnAxDlBS8PDp/BuZa9 hr3kcsyqPZpg3evV6P8tV/l4tBR9ANBP3GAsVCr3o/5jxfXiDYiKTVt4NH8KKWWYUoVL YrUXBGwPzQFP8c21mh9xZ6fUIXkYAp4Do8g1xfjsrw8bDlKxjRQG1UoRUxNicHRdsJLy BBG5MPXe3kDU/L6r/iEg+JLIi12xXmRPMTU1vG0pzQNC3KIuIJVaxHOEDrGCcFuysJs9 TfTIfJwMXYGqTT9OlmDI9/8B1Fg5GxOAYWNjA060B0B/GPd+cjBU+cOjPlDbj87AsxLA 0mgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Liy48y4J; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=vV9it4GN; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Liy48y4J; dkim=neutral (no key) header.i=@suse.de; 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.07.03.58; Wed, 23 Jun 2021 07:04:10 -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; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Liy48y4J; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=vV9it4GN; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Liy48y4J; dkim=neutral (no key) header.i=@suse.de; 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 S230243AbhFWOED (ORCPT + 99 others); Wed, 23 Jun 2021 10:04:03 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:52454 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231260AbhFWOD7 (ORCPT ); Wed, 23 Jun 2021 10:03:59 -0400 Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1B3891FD36; Wed, 23 Jun 2021 14:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624456901; h=from:from:reply-to: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=w/XMjSd1ArDZiIdvvGl7Gc1Zip3z1VcHSbThBZcRsbU=; b=Liy48y4JOsar34wdSnIy6K5wq1ggqhq6uhJwS3fOzYB6q+I9JmDN7Semc1W+vqgcijH8kP OxT8FNFGp8bGHL1afLHaWHL7rDIAbiIMaveQtXCVeuw5/HjBwg1eszoRrUUcy/nfa3z8/p ICjBvLTTts9DdFwMiuBucu2L65nmBuA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624456901; h=from:from:reply-to: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=w/XMjSd1ArDZiIdvvGl7Gc1Zip3z1VcHSbThBZcRsbU=; b=vV9it4GNyXZqJ98l4XIea1URtJ/rCX++dM0Jenmg4X9Yfr9ISPNGHxzFRRZ3srBwesAgTM N6yiVJ/Qg/qIyqBQ== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id A7EC711A97; Wed, 23 Jun 2021 14:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624456901; h=from:from:reply-to: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=w/XMjSd1ArDZiIdvvGl7Gc1Zip3z1VcHSbThBZcRsbU=; b=Liy48y4JOsar34wdSnIy6K5wq1ggqhq6uhJwS3fOzYB6q+I9JmDN7Semc1W+vqgcijH8kP OxT8FNFGp8bGHL1afLHaWHL7rDIAbiIMaveQtXCVeuw5/HjBwg1eszoRrUUcy/nfa3z8/p ICjBvLTTts9DdFwMiuBucu2L65nmBuA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624456901; h=from:from:reply-to: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=w/XMjSd1ArDZiIdvvGl7Gc1Zip3z1VcHSbThBZcRsbU=; b=vV9it4GNyXZqJ98l4XIea1URtJ/rCX++dM0Jenmg4X9Yfr9ISPNGHxzFRRZ3srBwesAgTM N6yiVJ/Qg/qIyqBQ== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id DRUgKMQ+02BcTwAALh3uQQ (envelope-from ); Wed, 23 Jun 2021 14:01:40 +0000 Subject: Re: [PATCH v3 1/6] block: add disk sequence number To: Lennart Poettering , 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 , Matthew Wilcox , JeffleXu References: <20210623105858.6978-1-mcroce@linux.microsoft.com> <20210623105858.6978-2-mcroce@linux.microsoft.com> From: Hannes Reinecke Message-ID: <3be63d9f-d8eb-7657-86dc-8d57187e5940@suse.de> Date: Wed, 23 Jun 2021 16:01:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/23/21 3:51 PM, Lennart Poettering wrote: > 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 > Well ... except that you'll need to keep track of the numbers (otherwise you wouldn't know if the numbers changed, right?). And if you keep track of the numbers you probably will have to implement an uevent listener to get the events in time. But if you have an uevent listener you will also get the add/remove events for these devices. And if you get add and remove events you can as well implement sequence numbers in your application, seeing that you have all information allowing you to do so. So why burden the kernel with it? Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer