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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,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 251E1C48BE5 for ; Wed, 23 Jun 2021 14:12:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 048E86023E for ; Wed, 23 Jun 2021 14:12:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231182AbhFWOOc (ORCPT ); Wed, 23 Jun 2021 10:14:32 -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