Re: Possible to undo subvol delete?
On 2014-12-05 13:11, Shriramana Sharma wrote: OK so from https://forums.opensuse.org/showthread.php/440209-ifconfig I learnt that it's because /sbin, /usr/sbin etc is not on the normal user's path on openSUSE (they are, on Kubuntu). Adding them to PATH fixes the situation. (I wasn't even able to do ifconfig without giving the password. No idea why this is the openSUSE default...) Probably because OpenSUSE/SLES are designed as enterprise distributions, and their primary use case is having a very small number of sysadmins and a potentially large number of normal users. Ubuntu et al. are designed primarily for PC's, where everyone is assumed to be equivalent to an administrator. Personally, I prefer a somewhat hybrid approach where everyone has *sbin in their path, but file permissions are used to control what non-administrators can run. smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn ahferro...@gmail.com wrote: Personally, I prefer a somewhat hybrid approach where everyone has *sbin in their path, but file permissions are used to control what non-administrators can run. This is exactly the same approach as Ubuntu, since non-superuser can't really do anything active (whether creating or deleting) with */sbin commands, but only querying (like ifconfig, btrfs subvol list etc). So this is not really hybrid of anything it seems. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 2014-12-08 09:16, Shriramana Sharma wrote: On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn ahferro...@gmail.com wrote: Personally, I prefer a somewhat hybrid approach where everyone has *sbin in their path, but file permissions are used to control what non-administrators can run. This is exactly the same approach as Ubuntu, since non-superuser can't really do anything active (whether creating or deleting) with */sbin commands, but only querying (like ifconfig, btrfs subvol list etc). So this is not really hybrid of anything it seems. IIRC, Ubuntu relies on the fact that normal users don't have the capabilities required for the privileged operations, as opposed to just not letting them run the binaries at all. smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Thu, Dec 04, 2014 at 07:36:34PM +0530, Shriramana Sharma wrote: Well I don't know about you, but I'm just running an openSUSE 13.2 system updated to Tumbleweed here, and even if I just hit btrfs enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I am getting: $ btrfs Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may require superuser privileges (eg. root). $ ... so what to say of btrfs subvol, whether followed by crea or del! Oh I see. That must be some clever shell addon that prints that if you don't have /sbin in PATH and try to call a command from that path. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Wed, Dec 03, 2014 at 02:54:14PM -0500, Zygo Blaxell wrote: Even with the tty/interactive shell detection in place? Maybe I understood the reference to lvm/mdadm tools wrong. My idea is that the scripts would work as now, no prompts there. How do we reliably distinguish between running in a script interactively, running in a script non-interactively, and running interactively? The first choice is to use isatty() function, but this would not be enough to detect #1, which would require an extra option to force the itneractive mode. I could easily run a script from the command line that creates and destroys subvols and runs for days or weeks (in fact, I quite often do). It would be a significant productivity hit if an upgrade made it stop every night waiting for confirmation from a user who went home hours ago and won't be back for hours more. Yeah, we want to avoid such surprises. Besides isatty, there could be more shell magic to detect the interactive mode reliably, I don't know. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
David, I'm just running default openSUSE 13.2 now (had to reinstall for other reasons) and it's there. It's not something I added. Given that you're also on either openSUSE or SLED/SLES, I'd expect your system to act similarly as well. If not, it's downright curious. I guess I'll ask around on the openSUSE Forum... -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
OK so from https://forums.opensuse.org/showthread.php/440209-ifconfig I learnt that it's because /sbin, /usr/sbin etc is not on the normal user's path on openSUSE (they are, on Kubuntu). Adding them to PATH fixes the situation. (I wasn't even able to do ifconfig without giving the password. No idea why this is the openSUSE default...) -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Thu, Dec 4, 2014 at 12:23 AM, David Sterba dste...@suse.cz wrote: On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote: Works for me without the root password on a Tumbleweed installation (without apparmor/selinux). Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed? The context was 'does creating a subvolume require root password'. Well I don't know about you, but I'm just running an openSUSE 13.2 system updated to Tumbleweed here, and even if I just hit btrfs enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I am getting: $ btrfs Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may require superuser privileges (eg. root). $ ... so what to say of btrfs subvol, whether followed by crea or del! On Kubuntu Trusty, doing the above at least gives me the help list of btrfs subcommands and only when I try to execute some actual *action* which requires privileges (like accessing some root-read-only file or such) do I get an error message for not using sudo. For some (wierd) reason SuSE (possibly thinking it's being helpful) is requiring me to use sudo and enter password for even just *running* the btrfs executable. If there were a way to disable this and/or get the Kubuntu behaviour it'd be great (but of course this is not a SuSE forum!). What seems weird to me here is that it says it *may* require root privileges but simply drops me back to the prompt -- it doesn't seem to check whether the executable *actually* requires root permission. Granted, if it's under /sbin or /ust/sbin, it probably does, but the wording is quite strange, and the behaviour stranger. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 2014-12-04 09:06, Shriramana Sharma wrote: On Thu, Dec 4, 2014 at 12:23 AM, David Sterba dste...@suse.cz wrote: On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote: Works for me without the root password on a Tumbleweed installation (without apparmor/selinux). Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed? The context was 'does creating a subvolume require root password'. Well I don't know about you, but I'm just running an openSUSE 13.2 system updated to Tumbleweed here, and even if I just hit btrfs enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I am getting: $ btrfs Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may require superuser privileges (eg. root). $ ... so what to say of btrfs subvol, whether followed by crea or del! On Kubuntu Trusty, doing the above at least gives me the help list of btrfs subcommands and only when I try to execute some actual *action* which requires privileges (like accessing some root-read-only file or such) do I get an error message for not using sudo. For some (wierd) reason SuSE (possibly thinking it's being helpful) is requiring me to use sudo and enter password for even just *running* the btrfs executable. If there were a way to disable this and/or get the Kubuntu behaviour it'd be great (but of course this is not a SuSE forum!). What seems weird to me here is that it says it *may* require root privileges but simply drops me back to the prompt -- it doesn't seem to check whether the executable *actually* requires root permission. Granted, if it's under /sbin or /ust/sbin, it probably does, but the wording is quite strange, and the behaviour stranger. AFAIK, the behavior is something in whatever patched version of whatever shell SuSE uses by default (IIRC, it's bash, but I'm not 100% certain about that). I would go looking in /etc/profile and the other system wide startup files for that shell to see if you could override the behavior there. It may also be something SELinux or file permissions related though. smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 02:09:45PM +, Hugo Mills wrote: On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote: export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 Ideas? Never rely on aliasing or environment variables for defaults, and never change default behavior if your releases are old enough that someone has built scripts on top of them. ;) Exactly. If I had to pick the least evil, I'd go for interactive prompting by default (do nothing if the interaction fails, e.g. no TTY) and add a '-f'/'--force' flag to bypass the prompt. This sounds acceptable. This is consistent with the way lvm2 and mdadm work when presented with data-losing or otherwise questionable commands and parameters. It will break scripts, but btrfs users should still be expecting that for a while as undesirable default behaviors are identified. How is this going to break scripts? Any script which relies on being able to delete subvolumes in unattended operation will now require modification to use -f. Even with the tty/interactive shell detection in place? Maybe I understood the reference to lvm/mdadm tools wrong. My idea is that the scripts would work as now, no prompts there. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote: On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: $ /sbin/btrfs sub create foo Create subvolume './foo' $ date foo/bar $ /sbin/btrfs sub delete foo Transaction commit: none (default) Delete subvolume '/home/testuser/foo' ERROR: cannot delete '/home/testuser/foo' - Operation not permitted $ rm -rf foo rm: cannot remove `foo': Operation not permitted $ cat /proc/version Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014 ...uh oh? That's how it works now. I'd like to enable the user to delete their subvolumes even without the user_subvol_rm_allowed option someday. That seems...odd. It should be symmetrical, i.e. if you can create a subvol you should be able to delete it, and if can't delete a subvol then you shouldn't be able to create them either. It should and I don't know the exact reasons why it's been restricted. AFAICS it should be safe to enable the user_subvol_rm_allowed mode by default. I can imagine quite a bit of havoc could be wrought by an unprivileged user creating subvols indiscriminately (or in various specific, targeted locations). Is this different from creating directories the same way? There is a difference in metadata consumption between subvolume and directory, but this would lead to just ENOSPC. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote: Works for me without the root password on a Tumbleweed installation (without apparmor/selinux). Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed? The context was 'does creating a subvolume require root password'. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 04:11:54PM +0900, Satoru Takeuchi wrote: Hi, (2014/11/30 12:33), Shriramana Sharma wrote: IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? [If no, then ordinary users should probably prefer regular directories to subvols.] One solution is using snapper instead of using btrfs directly. Snapper can automatically take a snapshot just before taking/deleting snapshots. So, if you delete a snapshot by mistake, it's still alive. Although snapper can create a pre/post pair of snapsthots for a given command 'snapper create -c a command', running subvolume deletion in place of 'a command' does not make sense to me. It's not clear how you intend to use snapper here. Let's say I'll configure it for some subvolume, turn on periodic snapshots and also create my own snapshots. The periodic (timeline) snapshots are created every hour, but what if I create my own snapshot, delete it accidentaly ... how does the snapper-snapshots help here? To be perfectly safe from accidental snapshot deletion in general, I'd have to always create two instances, and move one somewhere safe. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote: It's not a Btrfs itself's feature. It's a snapper's feature. It works as a helper of snapshot management. 1. You takes /snap by snapper create command. 2. You delete /snap by snapper delete command by mistake. Then snapper takes a pre snapshot just before deleting /snap. 3. Now /snap is deleted, however, a pre snapshot which is the same as /snap before deleting, is still alive. Can you please post exact commands how you achieve that? The 'create' subcommand may take a --type parameter, without it it creates 'single', and does not create pre or post snapshots automatically. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Wed, Dec 03, 2014 at 08:05:08AM +0530, Shriramana Sharma wrote: On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com wrote: 2. You delete /snap by snapper delete command by mistake. Then snapper takes a pre snapshot just before deleting /snap. 3. Now /snap is deleted, however, a pre snapshot which is the same as /snap before deleting, is still alive. I don't know how Btrfs itself undo the deletion of a snapshot. It works if you manages snapshots not by btrfs directly, but by snapper. If I misunderstanding something, sorry for noise. No nothing misunderstood. Excellent illustration. So using snapper is sorta like using the higher-level trash instead of lower-level rm, so that even after we delete, it's still available... I think there's some confusion, please refer to snapper documentation. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Wed, Dec 03, 2014 at 07:48:43PM +0100, David Sterba wrote: On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote: On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: $ /sbin/btrfs sub create foo Create subvolume './foo' $ date foo/bar $ /sbin/btrfs sub delete foo Transaction commit: none (default) Delete subvolume '/home/testuser/foo' ERROR: cannot delete '/home/testuser/foo' - Operation not permitted $ rm -rf foo rm: cannot remove `foo': Operation not permitted $ cat /proc/version Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014 ...uh oh? That's how it works now. I'd like to enable the user to delete their subvolumes even without the user_subvol_rm_allowed option someday. That seems...odd. It should be symmetrical, i.e. if you can create a subvol you should be able to delete it, and if can't delete a subvol then you shouldn't be able to create them either. It should and I don't know the exact reasons why it's been restricted. AFAICS it should be safe to enable the user_subvol_rm_allowed mode by default. I can imagine quite a bit of havoc could be wrought by an unprivileged user creating subvols indiscriminately (or in various specific, targeted locations). Is this different from creating directories the same way? 'rmdir' doesn't know how to delete an empty subvolume, so neither does 'rm -rf', 'rsync --delete', or probably a thousand other independently developed file-handling admin tools. buildbot:~# btrfs sub create /tmp/foo Create subvolume '/tmp/foo' buildbot:~# rmdir /tmp/foo rmdir: failed to remove `/tmp/foo': Operation not permitted It seems unreasonable to require all the existing admin tools to learn a new way to delete something that a non-root user can create, when we could just teach btrfs rmdir to delete subvols instead. There is a difference in metadata consumption between subvolume and directory, but this would lead to just ENOSPC. There's another subtle havoc-wreaking semantic difference between a directory and a subvolume: if a user has an open file on a subvolume, the file can be deleted, but the subvolume can't: buildbot:~# cd /tmp/foo buildbot:/tmp/foo# ls -l total 0 buildbot:/tmp/foo# exec 9file buildbot:/tmp/foo# date 9 buildbot:/tmp/foo# cat file Wed Dec 3 14:40:24 EST 2014 buildbot:/tmp/foo# rm file buildbot:/tmp/foo# cd .. buildbot:/tmp# ls foo/ buildbot:/tmp# btrfs sub del foo Transaction commit: none (default) Delete subvolume '/tmp/foo' ERROR: cannot delete '/tmp/foo' - Device or resource busy Close the file and subvol del works again: buildbot:/tmp# exec 9- buildbot:/tmp# btrfs sub del foo Transaction commit: none (default) Delete subvolume '/tmp/foo' buildbot:/tmp# ls foo/ ls: cannot access foo/: No such file or directory buildbot:/tmp# cat /proc/version Linux version 3.17.2-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Thu Nov 13 21:57:39 EST 2014 signature.asc Description: Digital signature
Re: Possible to undo subvol delete?
On Wed, Dec 03, 2014 at 07:26:33PM +0100, David Sterba wrote: On Tue, Dec 02, 2014 at 02:09:45PM +, Hugo Mills wrote: On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote: export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 Ideas? Never rely on aliasing or environment variables for defaults, and never change default behavior if your releases are old enough that someone has built scripts on top of them. ;) Exactly. If I had to pick the least evil, I'd go for interactive prompting by default (do nothing if the interaction fails, e.g. no TTY) and add a '-f'/'--force' flag to bypass the prompt. This sounds acceptable. This is consistent with the way lvm2 and mdadm work when presented with data-losing or otherwise questionable commands and parameters. It will break scripts, but btrfs users should still be expecting that for a while as undesirable default behaviors are identified. How is this going to break scripts? Any script which relies on being able to delete subvolumes in unattended operation will now require modification to use -f. Even with the tty/interactive shell detection in place? Maybe I understood the reference to lvm/mdadm tools wrong. My idea is that the scripts would work as now, no prompts there. How do we reliably distinguish between running in a script interactively, running in a script non-interactively, and running interactively? I could easily run a script from the command line that creates and destroys subvols and runs for days or weeks (in fact, I quite often do). It would be a significant productivity hit if an upgrade made it stop every night waiting for confirmation from a user who went home hours ago and won't be back for hours more. signature.asc Description: Digital signature
Re: Possible to undo subvol delete?
Hi David, (2014/12/04 4:12), David Sterba wrote: On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote: It's not a Btrfs itself's feature. It's a snapper's feature. It works as a helper of snapshot management. 1. You takes /snap by snapper create command. 2. You delete /snap by snapper delete command by mistake. Then snapper takes a pre snapshot just before deleting /snap. 3. Now /snap is deleted, however, a pre snapshot which is the same as /snap before deleting, is still alive. Can you please post exact commands how you achieve that? The 'create' subcommand may take a --type parameter, without it it creates 'single', and does not create pre or post snapshots automatically. Oh, I misunderstood the concept of snapper and my explanation was wrong. I apologize you, David and Shriramana. I confused taking automatic pre/post snapshots at YAST and something and on deleting snapshots. snapper delete doesn't take pre snapshot. Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote: export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 Ideas? Never rely on aliasing or environment variables for defaults, and never change default behavior if your releases are old enough that someone has built scripts on top of them. ;) Exactly. If I had to pick the least evil, I'd go for interactive prompting by default (do nothing if the interaction fails, e.g. no TTY) and add a '-f'/'--force' flag to bypass the prompt. This sounds acceptable. This is consistent with the way lvm2 and mdadm work when presented with data-losing or otherwise questionable commands and parameters. It will break scripts, but btrfs users should still be expecting that for a while as undesirable default behaviors are identified. How is this going to break scripts? OTOH maybe there is no issue with the current behavior. Only root can delete subvolumes, and maybe we assume root knows what they're doing? With the mount option user_subvol_rm_allowed the user can delete subvols as well, so it makes sense to add the confirmation. On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: $ /sbin/btrfs sub create foo Create subvolume './foo' $ date foo/bar $ /sbin/btrfs sub delete foo Transaction commit: none (default) Delete subvolume '/home/testuser/foo' ERROR: cannot delete '/home/testuser/foo' - Operation not permitted $ rm -rf foo rm: cannot remove `foo': Operation not permitted $ cat /proc/version Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014 ...uh oh? That's how it works now. I'd like to enable the user to delete their subvolumes even without the user_subvol_rm_allowed option someday. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 09:10:15AM +0530, Shriramana Sharma wrote: On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: Not sure about your Debian system, but my openSUSE Tumbleweed (with kernel 3.17.2 and btrfsprogs 3.17) requires me to enter the root password before creating a subvol (or in fact running anything under /sbin or /usr/sbin). Works for me without the root password on a Tumbleweed installation (without apparmor/selinux). -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote: export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 Ideas? Never rely on aliasing or environment variables for defaults, and never change default behavior if your releases are old enough that someone has built scripts on top of them. ;) Exactly. If I had to pick the least evil, I'd go for interactive prompting by default (do nothing if the interaction fails, e.g. no TTY) and add a '-f'/'--force' flag to bypass the prompt. This sounds acceptable. This is consistent with the way lvm2 and mdadm work when presented with data-losing or otherwise questionable commands and parameters. It will break scripts, but btrfs users should still be expecting that for a while as undesirable default behaviors are identified. How is this going to break scripts? Any script which relies on being able to delete subvolumes in unattended operation will now require modification to use -f. Hugo. -- Hugo Mills | Unix: For controlling fungal diseases in crops hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: 65E74AC0 | signature.asc Description: Digital signature
Re: Possible to undo subvol delete?
On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote:
Works for me without the root password on a Tumbleweed installation
(without apparmor/selinux).
Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
N�r��yb�X��ǧv�^�){.n�+{�n�߲)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: Possible to undo subvol delete?
On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com wrote: Snapper can automatically take a snapshot just before taking/deleting snapshots. So, if you delete a snapshot by mistake, it's still alive. Sorta contradicts the whole point of deleting a snapshot, no? Or is it some sort of trash vs (real) delete mechanism? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: $ /sbin/btrfs sub create foo Create subvolume './foo' $ date foo/bar $ /sbin/btrfs sub delete foo Transaction commit: none (default) Delete subvolume '/home/testuser/foo' ERROR: cannot delete '/home/testuser/foo' - Operation not permitted $ rm -rf foo rm: cannot remove `foo': Operation not permitted $ cat /proc/version Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014 ...uh oh? That's how it works now. I'd like to enable the user to delete their subvolumes even without the user_subvol_rm_allowed option someday. That seems...odd. It should be symmetrical, i.e. if you can create a subvol you should be able to delete it, and if can't delete a subvol then you shouldn't be able to create them either. I can imagine quite a bit of havoc could be wrought by an unprivileged user creating subvols indiscriminately (or in various specific, targeted locations). signature.asc Description: Digital signature
Re: Possible to undo subvol delete?
(2014/12/03 0:17), Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com wrote: Snapper can automatically take a snapshot just before taking/deleting snapshots. So, if you delete a snapshot by mistake, it's still alive. Sorta contradicts the whole point of deleting a snapshot, no? Or is it some sort of trash vs (real) delete mechanism? It's not a Btrfs itself's feature. It's a snapper's feature. It works as a helper of snapshot management. 1. You takes /snap by snapper create command. 2. You delete /snap by snapper delete command by mistake. Then snapper takes a pre snapshot just before deleting /snap. 3. Now /snap is deleted, however, a pre snapshot which is the same as /snap before deleting, is still alive. I don't know how Btrfs itself undo the deletion of a snapshot. It works if you manages snapshots not by btrfs directly, but by snapper. If I misunderstanding something, sorry for noise. Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com wrote: 2. You delete /snap by snapper delete command by mistake. Then snapper takes a pre snapshot just before deleting /snap. 3. Now /snap is deleted, however, a pre snapshot which is the same as /snap before deleting, is still alive. I don't know how Btrfs itself undo the deletion of a snapshot. It works if you manages snapshots not by btrfs directly, but by snapper. If I misunderstanding something, sorry for noise. No nothing misunderstood. Excellent illustration. So using snapper is sorta like using the higher-level trash instead of lower-level rm, so that even after we delete, it's still available... -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 2014-11-29 23:23, Marc MERLIN wrote: On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote: IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? If you didn't snapshot that volume before deleting it, you're SOL. If you snapshotted it, rename that snapshot to the other name, and you're done. Btrfs doesn't offer undelete, it only lets you keep multiple copies of your data at very little cost, so you can retrieve a snapshot copy if you deleted your current volume's data. Marc Well, in theory, if you unmount the FS _immediately_ after the subvol delete, without writing _anything_ else to it, it _might_ be possible to recover the data using some (probably almost incomprehensible) incantation of btrfs-find-root and btrfs recover/restore. In practice though, for anyone who doesn't have expert level knowledge of the on-disk structure and fs internals, deleting a subvolume can't be undone. We might want to consider adding an option to btrfs subvol del to ask for confirmation (or make it do so by default and add an option to disable asking for confirmation). smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Mon, Dec 1, 2014 at 6:42 PM, Austin S Hemmelgarn ahferro...@gmail.com wrote: We might want to consider adding an option to btrfs subvol del to ask for confirmation (or make it do so by default and add an option to disable asking for confirmation). I already reported: https://bugzilla.kernel.org/show_bug.cgi?id=89091. As I requested there, I prefer for confirmation by default and -f to force otherwise, rather than behaviour of rm which requires -i to ask confirmation. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
2014-12-01 14:12 GMT+01:00 Austin S Hemmelgarn ahferro...@gmail.com: We might want to consider adding an option to btrfs subvol del to ask for confirmation (or make it do so by default and add an option to disable asking for confirmation). I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume deletions with exact btrfs subvolume delete commands, and they should be protected against an ordinary rm. There also could be a tunable FS feature to allow or disable ordinary subvolume deletions, which could be set or unset by btrfstune. I think a subvolume really deserves to be treated specially over an ordinary directory. As for undeletion, while I have no idea how to do that, I noticed they don't get deleted immediately. With older btrfs tools (3.12), I noticed, if I delete a subvolume and then immediately issue a btrfs subvolume list, my deleted subvolume is still listed with a DELETED caption, and allocated space doesn't immediately gets freed if I check with df -m. It takes a few seconds for the DELETED entry to disappear and the allocated space to be freed. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, 1 Dec 2014 18:49:23 +0530 Shriramana Sharma samj...@gmail.com wrote: As I requested there, I prefer for confirmation by default and -f to force otherwise, rather than behaviour of rm which requires -i to ask confirmation. And I prefer the current behavior (also replied on the bug). A more sensible idea could be adding a global-level '-i' switch, same as in 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask confirmation on any irreversible action). -- With respect, Roman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, 1 Dec 2014 14:38:16 +0100 MegaBrutal megabru...@gmail.com wrote: I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume deletions with exact btrfs subvolume delete commands, and they This is already the case. 'rm -r' will remove all files in a subvolume, but the empty subvolume itself is only deletable via the 'btrfs' command. If you want to make snapshots which can't be removed by ordinary tools, use the 'read-only' mode when creating them. -- With respect, Roman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 2014-12-01 08:38, MegaBrutal wrote: 2014-12-01 14:12 GMT+01:00 Austin S Hemmelgarn ahferro...@gmail.com: We might want to consider adding an option to btrfs subvol del to ask for confirmation (or make it do so by default and add an option to disable asking for confirmation). I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume deletions with exact btrfs subvolume delete commands, and they should be protected against an ordinary rm. There also could be a tunable FS feature to allow or disable ordinary subvolume deletions, which could be set or unset by btrfstune. I think a subvolume really deserves to be treated specially over an ordinary directory. I don't know what distro/kernel version you might be using, but every version of btrfs I have used required the use of 'btrfs subvol del' to actually delete a subvolume, even an empty one. It would not surprise me though if RHEL or SuSE had patched the kernel to allow using rm on a subvolume. smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Mon, 01 Dec 2014 14:38:16 +0100, MegaBrutal wrote: I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume Nope: rootbtrfs subvolume create foo Create subvolume './foo' roottouch foo/bla rootll foo total 0 -rw-r--r-- 1 root root 0 Dec 1 14:47 bla rootrm -rf foo rm: cannot remove ‘foo’: Operation not permitted root The files of the subvolume do get deleted though, but that's correct. Not sure what you did, but what you want is already the case. -h -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
2014-12-01 14:47 GMT+01:00 Roman Mamedov r...@romanrm.net: On Mon, 1 Dec 2014 14:38:16 +0100 MegaBrutal megabru...@gmail.com wrote: I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume deletions with exact btrfs subvolume delete commands, and they This is already the case. 'rm -r' will remove all files in a subvolume, but the empty subvolume itself is only deletable via the 'btrfs' command. That's great! And there is no way to protect against recursive deletions (besides setting the subvolume read-only, as you suggested below), as files are processes individually by rm. But it's OK, people should always be very careful with rm, and it doesn't change with btrfs. ;) If you want to make snapshots which can't be removed by ordinary tools, use the 'read-only' mode when creating them. Yeah, good idea! Anyway, is it possible to change a read-only snapshot to read-write and vica-versa, or you can only specify read-only while creating them? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov r...@romanrm.net wrote: A more sensible idea could be adding a global-level '-i' switch, same as in 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask confirmation on any irreversible action). Well the difference being that there doesn't seem to be any other irreversible action from my scan of man btrfs -- am I missing anything? This is the only thing that actually leads to loss of data. When btrfs has so many features (esp snapshots) to prevent user accidentally deleting data (I liked especially http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to be *some* modicum of support for warning against deleting a subvolume (and it seems others agree too). But I see what you mean in the bugzilla comment about not wanting your existing backup snapshot scripts to fail because they don't have a -f. At the same time, aliasing via -i on top level btrfs binary may not be so practical here because this is the only command which will actually use it (again, correct if wrong). Perhaps exporting some envvar in the default shell's rc file (or whichever file will be read only if the shell is interactive) would work? Like in ~/.bashrc: export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 Ideas? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, Dec 1, 2014 at 7:24 PM, MegaBrutal megabru...@gmail.com wrote: If you want to make snapshots which can't be removed by ordinary tools, use the 'read-only' mode when creating them. Yeah, good idea! Anyway, is it possible to change a read-only snapshot to read-write and vica-versa, or you can only specify read-only while creating them? IIUC you can only specify RO while creating but you can always cheaply create a RW snapshot of an RO one or an RO snapshot of an RW one... -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 12/01/2014 08:40 AM, Shriramana Sharma wrote: IIUC you can only specify RO while creating but you can always cheaply create a RW snapshot of an RO one or an RO snapshot of an RW one... You can turn ReadOnly status on and off (er. true and false) with btrfs property get/set ro=true/false /path/to/subvolume -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On 2014-12-01 08:54, MegaBrutal wrote: 2014-12-01 14:47 GMT+01:00 Roman Mamedov r...@romanrm.net: On Mon, 1 Dec 2014 14:38:16 +0100 MegaBrutal megabru...@gmail.com wrote: I've also noticed, a subvolume can just be deleted with an rm -r, just like an ordinary directory. I'd consider to only allow subvolume deletions with exact btrfs subvolume delete commands, and they This is already the case. 'rm -r' will remove all files in a subvolume, but the empty subvolume itself is only deletable via the 'btrfs' command. That's great! And there is no way to protect against recursive deletions (besides setting the subvolume read-only, as you suggested below), as files are processes individually by rm. But it's OK, people should always be very careful with rm, and it doesn't change with btrfs. ;) If you want to make snapshots which can't be removed by ordinary tools, use the 'read-only' mode when creating them. Yeah, good idea! Anyway, is it possible to change a read-only snapshot to read-write and vica-versa, or you can only specify read-only while creating them? IIRC, there is something that you can do with the properties interface. Personally though, I just make the snapshot RW to start with, and then recursively make it immutable (chattr -r +I), as I never use immutable files for anything else, and it works on any _sane_ filesystem, not just btrfs. smime.p7s Description: S/MIME Cryptographic Signature
Re: Possible to undo subvol delete?
On Mon, Dec 01, 2014 at 08:50:09AM -0500, Austin S Hemmelgarn wrote: It would not surprise me though if RHEL or SuSE had patched the kernel to allow using rm on a subvolume. This would be quite a big change in behaviour that we would not do without taking it upstream first. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, Dec 01, 2014 at 08:12:02AM -0500, Austin S Hemmelgarn wrote: On 2014-11-29 23:23, Marc MERLIN wrote: On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote: IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? If you didn't snapshot that volume before deleting it, you're SOL. If you snapshotted it, rename that snapshot to the other name, and you're done. Btrfs doesn't offer undelete, it only lets you keep multiple copies of your data at very little cost, so you can retrieve a snapshot copy if you deleted your current volume's data. Marc Well, in theory, if you unmount the FS _immediately_ after the subvol delete, without writing _anything_ else to it, it _might_ be possible to recover the data using some (probably almost incomprehensible) incantation of btrfs-find-root and btrfs recover/restore. In practice though, for anyone who doesn't have expert level knowledge of the on-disk structure and fs internals, deleting a subvolume can't be undone. Agreed, though there's not so much magic involved. Deleting a subvolume means removing the directory entry and the backrefrence. Undoing that can make the subvolume live again, although the dir/name and original parent tree cannot be reconstructed. I'll add it to the project ideas. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Mon, Dec 01, 2014 at 10:09:44PM +0530, Shriramana Sharma wrote:
On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov r...@romanrm.net wrote:
A more sensible idea could be adding a global-level '-i' switch, same as in
'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask
confirmation on any irreversible action).
Well the difference being that there doesn't seem to be any other
irreversible action from my scan of man btrfs -- am I missing
anything? This is the only thing that actually leads to loss of data.
When btrfs has so many features (esp snapshots) to prevent user
accidentally deleting data (I liked especially
http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
be *some* modicum of support for warning against deleting a subvolume
(and it seems others agree too).
But I see what you mean in the bugzilla comment about not wanting your
existing backup snapshot scripts to fail because they don't have a -f.
At the same time, aliasing via -i on top level btrfs binary may not be
so practical here because this is the only command which will actually
use it (again, correct if wrong).
Perhaps exporting some envvar in the default shell's rc file (or
whichever file will be read only if the shell is interactive) would
work? Like in ~/.bashrc:
export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
Ideas?
Never rely on aliasing or environment variables for defaults, and never
change default behavior if your releases are old enough that someone
has built scripts on top of them. ;)
fprintf(stderr, Deleting subvolume '%s' in 5 seconds.\n, subvol_path);
if (!f_flag_on_cmd_line) {
fprintf(stderr, If this is not what you want,\n);
fprintf(stderr, *** PRESS Ctrl-C TO ABORT NOW!!! ***\a\n);
sleep(5);
}
Of course, in an init-shell-type environment, Ctrl-C doesn't work
either...
If I had to pick the least evil, I'd go for interactive prompting by
default (do nothing if the interaction fails, e.g. no TTY) and add a
'-f'/'--force' flag to bypass the prompt. This is consistent with the
way lvm2 and mdadm work when presented with data-losing or otherwise
questionable commands and parameters. It will break scripts, but btrfs
users should still be expecting that for a while as undesirable default
behaviors are identified.
OTOH maybe there is no issue with the current behavior. Only root can
delete subvolumes, and maybe we assume root knows what they're doing?
On a side note...only root can delete subvolumes, but non-root users
can create them, which results in...this:
$ /sbin/btrfs sub create foo
Create subvolume './foo'
$ date foo/bar
$ /sbin/btrfs sub delete foo
Transaction commit: none (default)
Delete subvolume '/home/testuser/foo'
ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
$ rm -rf foo
rm: cannot remove `foo': Operation not permitted
$ cat /proc/version
Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian
4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014
...uh oh?
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
Re: Possible to undo subvol delete?
On Tue, Dec 2, 2014 at 8:44 AM, Zygo Blaxell ce3g8...@umail.furryterror.org wrote: This is consistent with the way lvm2 and mdadm work when presented with data-losing or otherwise questionable commands and parameters. It will break scripts, but btrfs users should still be expecting that for a while as undesirable default behaviors are identified. Ah so there *is* precedent for my hunch that deleting subvols should be different than deleting ordinary files and folders... :-) OTOH maybe there is no issue with the current behavior. Only root can delete subvolumes, and maybe we assume root knows what they're doing? Well in office environs, where the root password is with a certain person only, then that's fine because that person is going to be wary of doing anything that's make others angry at them, but on single-user systems, one's regular password *is* the root password and the situation is such that because ordinary (and mostly non-destructive) things like installing requires entering it, so one gets accustomed to entering it without too much thought, leading to the requirement for such safety nets. (Perhaps like in banks, we should have a two-password system, one for destructive actions, so the user is forced to apply thought to what they are approving!) On a side note...only root can delete subvolumes, but non-root users can create them, which results in...this: Not sure about your Debian system, but my openSUSE Tumbleweed (with kernel 3.17.2 and btrfsprogs 3.17) requires me to enter the root password before creating a subvol (or in fact running anything under /sbin or /usr/sbin). -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
2014-12-01 17:39 GMT+01:00 Shriramana Sharma samj...@gmail.com: When btrfs has so many features (esp snapshots) to prevent user accidentally deleting data (I liked especially http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to be *some* modicum of support for warning against deleting a subvolume (and it seems others agree too). WOW, this is pretty neat? How can I do the same actions from the command-line? E.g. I would be curious whether a file changed since the last snapshot. Today I have to use traditional methods like plain ls -l (in case I trust the time file size), or diff. But in the video we could see a directory in a view when we only seen the changed files. How does that YaST application do so? And is there a more enegant way to restore files to their originals than a plain mv? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
2014-12-02 4:40 GMT+01:00 Shriramana Sharma samj...@gmail.com: Well in office environs, where the root password is with a certain person only, then that's fine because that person is going to be wary of doing anything that's make others angry at them, but on single-user systems, one's regular password *is* the root password and the situation is such that because ordinary (and mostly non-destructive) things like installing requires entering it, so one gets accustomed to entering it without too much thought, leading to the requirement for such safety nets. It reminds me of this accidental deletion: http://serverfault.com/questions/587102/monday-morning-mistake-sudo-rm-rf-no-preserve-root LOL at How do you even type --no-preserve-root accidentally?! :-o. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Tue, Dec 02, 2014 at 06:33:38AM +0100, MegaBrutal wrote: 2014-12-01 17:39 GMT+01:00 Shriramana Sharma samj...@gmail.com: When btrfs has so many features (esp snapshots) to prevent user accidentally deleting data (I liked especially http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to be *some* modicum of support for warning against deleting a subvolume (and it seems others agree too). WOW, this is pretty neat? How can I do the same actions from the command-line? E.g. I would be curious whether a file changed since the last snapshot. Today I have to use traditional methods like plain ls It's not trivial. See http://marc.merlins.org/perso/btrfs/2014-05.html#Btrfs-diff-Between-Snapshots From what I understand, the only way to do this better is to use btrfs-send and parse the output, but that's not trivial either since btrfs-send has lots of intermediate renames. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
Hi, (2014/11/30 12:33), Shriramana Sharma wrote: IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? [If no, then ordinary users should probably prefer regular directories to subvols.] One solution is using snapper instead of using btrfs directly. Snapper can automatically take a snapshot just before taking/deleting snapshots. So, if you delete a snapshot by mistake, it's still alive. For more information, please refer to the following URLs. https://en.opensuse.org/Portal:Snapper http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Europe_2014_Full_system_rollback_btrfs_snapper_0.pdf Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible to undo subvol delete?
IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? [If no, then ordinary users should probably prefer regular directories to subvols.] -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible to undo subvol delete?
On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote: IIUC with BtrFS while it is possible to easily undelete a file or ordinary directory if a snapshot of the containing subvol exists, it seems that it's not elementary to undelete a subvol itself, because all subvols are under the root-level subvol (id 0 or 5, see my other q) but even snapshotting the root subvol will not snapshot any subvols under it. So is there any way to undo a subvol delete? If you didn't snapshot that volume before deleting it, you're SOL. If you snapshotted it, rename that snapshot to the other name, and you're done. Btrfs doesn't offer undelete, it only lets you keep multiple copies of your data at very little cost, so you can retrieve a snapshot copy if you deleted your current volume's data. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
