From: Graham Cobb <email@example.com> To: Marcos Paulo de Souza <firstname.lastname@example.org>, email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 5/5] btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion Date: Fri, 25 Oct 2019 13:00:33 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 24/10/2019 03:36, Marcos Paulo de Souza wrote: > From: Marcos Paulo de Souza <email@example.com> > > 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). 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. Graham
next prev parent reply other threads:[~2019-10-25 12:06 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-24 2:36 [PATCH 0/5] btrfs: send uevent on subvolume add/remove Marcos Paulo de Souza 2019-10-24 2:36 ` [PATCH 1/5] btrfs: sysfs: Add envp argument to btrfs_kobject_uevent Marcos Paulo de Souza 2019-10-24 2:36 ` [PATCH 2/5] btrfs: ioctl: Introduce btrfs_vol_uevent Marcos Paulo de Souza 2019-10-24 2:36 ` [PATCH 3/5] btrfs: ioctl: Call btrfs_vol_uevent on subvol creation Marcos Paulo de Souza 2019-10-24 2:36 ` [PATCH 4/5] btrfs: ctree.h: Add btrfs_is_snapshot function Marcos Paulo de Souza 2019-10-25 10:02 ` Filipe Manana 2019-10-24 2:36 ` [PATCH 5/5] btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion Marcos Paulo de Souza 2019-10-25 12:00 ` Graham Cobb [this message] 2019-10-25 15:44 ` Marcos Paulo de Souza 2019-11-18 20:50 ` [PATCH 0/5] btrfs: send uevent on subvolume add/remove David Sterba
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 5/5] btrfs: ioctl: Call btrfs_vol_uevent on subvolume deletion' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).