Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5701821pxj; Wed, 23 Jun 2021 07:13:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9XpUPR8/eeVl3xUbnv+ng+MkZdZCDNp6efUG0Bb2aNI3+hl9dCm1jyk0q77ljUOC1MlZp X-Received: by 2002:a05:6402:d6a:: with SMTP id ec42mr12743511edb.211.1624457637680; Wed, 23 Jun 2021 07:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624457637; cv=none; d=google.com; s=arc-20160816; b=cNnKQ/OPe3P0cdCObvQoBL9w23sxA7zVdvBho4A/2+iRUAfhkTADXMmrkTI5/MXWOW SuSezmqbP0GBBEe9NqyxbBzI1dg3Unmssijz6p5Bdlkr6yR+oNOwUkdY8kKLEkSKPh1e eGVWt9t0YgsgAocwAdnQXjUvgy92rXmNE6tEY+0/QSDfsqXBAwKgBTtun3MsC3gsKWk5 Mq0uQgTCoGqBhL7/sGxbp7NvdferBljqd/UDH58p05b0Ud6oRJBRAiYAau5gMT2FMUCI HhuJoUg4w+qI8u/M45QGWoddaA4HTwY4a7j//+9X/ennn/kIER/SPCO18KaWUOaMs0tF g6gQ== 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=o7Vhj1buS/tBYo/XIlLSCPaxFkf/WD3gWIrHFmyY2s4=; b=lZnlJ/PukA23uPhdcrbmJjM6xoOJbZkAgseP5r6GnIXaL1jqy/SS0igTEZOAk3BaVe 32RLVx4q/o2BWQehhmYNgUkVaRx7YUa1PmMPjfN5uwONT6qI8w4VpPPTOAh4HEC8shaF LWL9V2gMP2XNcBGN+jFT/zoPr+DrmkHI1zi+T2kycIGlqIgPg3iQ3nYZ3u+LyFLNNXuX BSVg7ly77td7nvKW98iSdnck9SEi8xasyQmBIaU1JLHsPE2ejIxIkau+sGGEpInq2+8+ p3BhntRFxAuPCXe/DIgtZ3tVJw9vvEt6RjhuM7TvWfjncTBR71oRMmUZimkGcRlId3iu YJcw== 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 bf13si16138893edb.186.2021.06.23.07.13.34; Wed, 23 Jun 2021 07:13:57 -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 S230498AbhFWOOb (ORCPT + 99 others); Wed, 23 Jun 2021 10:14:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230274AbhFWOOb (ORCPT ); Wed, 23 Jun 2021 10:14:31 -0400 Received: from gardel.0pointer.net (gardel.0pointer.net [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A38FAC061574; Wed, 23 Jun 2021 07:12:13 -0700 (PDT) Received: from gardel-login.0pointer.net (gardel-mail [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by gardel.0pointer.net (Postfix) with ESMTP id 0FA6BE8094B; Wed, 23 Jun 2021 16:12:12 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id B4131160DC0; Wed, 23 Jun 2021 16:12:11 +0200 (CEST) Date: Wed, 23 Jun 2021 16:12:11 +0200 From: Lennart Poettering To: Hannes Reinecke Cc: Matteo Croce , 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 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> <3be63d9f-d8eb-7657-86dc-8d57187e5940@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3be63d9f-d8eb-7657-86dc-8d57187e5940@suse.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mi, 23.06.21 16:01, Hannes Reinecke (hare@suse.de) wrote: > > 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. Hmm? This is backwards. The goal here is to be able to safely match up uevents to specific uses of a block device, given that block device names are agressively recycled. you imply it was easy to know which device use a uevent belongs to. But that's the problem: it is not possible to do so safely. if i see a uevent for a block device "loop0" I cannot tell if it was from my own use of the device or for some previous user of it. And that's what we'd like to see fixed: i.e. we query the block device for the seqeno now used and then we can use that to filter the uevents and ignore the ones that do not carry the same sequence number as we got assigned for our user. Lennart -- Lennart Poettering, Berlin