Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4125164ybg; Fri, 25 Oct 2019 13:43:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqyjrw0VHuHgb6mx/sv5jPPdriI7Z9+S4mqmCf6G01bhQsAsn503QwxRuCgr3a5Ww0ATBJdq X-Received: by 2002:a50:fa42:: with SMTP id c2mr6238784edq.112.1572036230825; Fri, 25 Oct 2019 13:43:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572036230; cv=none; d=google.com; s=arc-20160816; b=ZDHLhfaCNnO5be2M+kcNL6f9Iab5kmXUK00s72CctlslKQ5hl/dnBnzvVD5wFIw1NG 3jzmXoUx9Faav4LX+vTB4DnX4cSG+RBFra/NW1X+Qze3yexxyYM990he1AQqQkHMVSG1 /w93mKlQRxIO8pBPh14iQsqmiC9CC1o81T1CMnouI5/a1hIyQFobJyU9ZJ3QyWmG5BcL 3XC2NIDfWwWeh0Lv2gGYOB4QbWh07HEt9IZAXNkjtV+C5cXcQY1++ZyambWWwGpVBBe5 vJqcBbACYmAQZHF9kl5BqJ+AMq2r5HB0F77Px6xh2O/rU4Kfz4clUrvrByX6exMiIEAD bytQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=6oUIoOlBuWnOecg0I4Tm4R6304Rp8QXx7vCNqEgg27A=; b=uVMaupWQofpHvgkAyounnw2C6bNHqTR21vuf6rTRnZpbi6fYjbGRl+sOjynGEcWBLi 97QYXYS8X5stBct3Xcq0w0leo0vetLTpaFrs6bEugAv0Y7sBZwc9A8a27KfQRCUiVSXl dNTQTq9ImnRCwA/F9K8+irkDUYtwxDvsTXAjGL1HRWqwPze0bOhUJ8+d9Ui1cnWFrvoR /LsTlMPd7Ow5S6NF+yaywYFavxXjMe/cmZZ9TVujHuYecIFRkpcWGP7nxp2bWqZmWnNN KnEAeiTlI4ggGIMb1pJGGVeZpnh4WyXbQjuQFncz8wiEvgoKzDk1bDrbq7vr6CfHNvl5 3zwg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l40si2001682edb.432.2019.10.25.13.43.27; Fri, 25 Oct 2019 13:43:50 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395482AbfJYPmN (ORCPT + 99 others); Fri, 25 Oct 2019 11:42:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:46336 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730508AbfJYPmN (ORCPT ); Fri, 25 Oct 2019 11:42:13 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 995DFB291; Fri, 25 Oct 2019 15:42:11 +0000 (UTC) Message-ID: <06601cbe64c98b2a9f0fa13a4e00401ae5d4387b.camel@suse.de> Subject: Re: [PATCH 5/5] btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion From: Marcos Paulo de Souza To: Graham Cobb , Marcos Paulo de Souza , linux-kernel@vger.kernel.org Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, mpdesouza@suse.com Date: Fri, 25 Oct 2019 12:44:20 -0300 In-Reply-To: References: <20191024023636.21124-1-marcos.souza.org@gmail.com> <20191024023636.21124-6-marcos.souza.org@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2019-10-25 at 13:00 +0100, Graham Cobb wrote: > On 24/10/2019 03:36, Marcos Paulo de Souza wrote: > > From: Marcos Paulo de Souza > > > > Since the function btrfs_ioctl_snap_destroy is used for deleting > both > > subvolumes and snapshots it was needed call btrfs_is_snapshot, > > which checks a giver btrfs_root and returns true if it's a > snapshot. > > The current code is interested in subvolumes only. > > To me, as a user, a snapshot *is* a subvolume. I don't even know what > "is a snapshot" means. Does it mean "was created using the btrfs > subvolume snapshot command"? Does it matter whether the snapshot has > been modified? Whether the originally snapshot subvolume still > exists? > Or what? > > I note that the man page for "btrfs subvolume" says "A snapshot is a > subvolume like any other, with given initial content.". And I > certainly > have some subvolumes which are being used as normal parts of the > filesystem, which were originally created as snapshots (for various > reasons, including reverting changes and going back to an earlier > snapshot, or an easy way to make sure that large common files are > actually sharing blocks). Agreed. > > I would expect this event would be generated for any subvolume > deletion. > If it is useful to distinguish subvolumes originally created as > snapshots in some way then export another flag (named to make it > clear > what it really indicates, such as BTRFS_VOL_FROM_SNAPSHOT). I don't > know > your particular purpose, but my guess is that a more useful flag > might > actually be BTRFS_VOL_FROM_READONLY_SNAPSHOT. As soon as these patches got merged I will send new ones to take care of snapshoting. Same things: when a snapsoht is created or removed, send a uevent. I liked this idea to separate both snapshots and volumes at first to make things simpler, and get reviews faster. Also, I think it's good to separate subvolumes and snapshot events, makes easier for one to filter such events. Marcos > > Graham