Bug 93021 - Mounted subvolumes can be deleted
Summary: Mounted subvolumes can be deleted
Status: REOPENED
Alias: None
Product: File System
Classification: Unclassified
Component: btrfs (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Josef Bacik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-10 07:44 UTC by Timo Kokkonen
Modified: 2018-09-07 08:19 UTC (History)
3 users (show)

See Also:
Kernel Version: v3.19
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Timo Kokkonen 2015-02-10 07:44:40 UTC
Steps to reproduce:

0) Default subvolume is left its default, eg. it is /

1) Create an empty subvolume and place a root file system under it

2) Boot with kernel command line such as: root=/dev/mmcblk0p3 rw rootwait rootflags=subvol=/623

3) Mount the root subvolume eg. with: "mount /dev/mmcblk0p3 /mnt" so that the subvolume 632 becomes accessible for example snapshotting.

4) Try to delete the subvolume called 623 (the only subvolume in addition to root subvolume, the one where we are running the root file system)

Obviously we should fail here, but we don't. From this point on, we no longer have the subvolume where the root file system is located. And we are no longer able to read directory listing from / directory (which now points to the subvolume that does not exist any more), but at least some shell commands appear to be still working for a while, at least those that have working directory held open somewhere else than at /. Everything appears to be working normally except that the root directory is suddenly deleted.

I don't think this was possible until 3.19. I have been triggering this with my scripts many times by now since we started using 3.19, never had any issues with previous kernel versions.
Comment 1 Timo Kokkonen 2015-03-26 06:46:24 UTC
Still reproducible with 4.0-rc4
Comment 2 Timo Kokkonen 2015-05-27 06:11:02 UTC
It appears this is no longer reproducible with 4.1-rc4. So I'll mark this as resolved.
Comment 3 David Sterba 2015-05-27 09:53:33 UTC
Strange, I don't see any patch in btrfs that could fix that.

http://article.gmane.org/gmane.linux.kernel/1920175 from Omar is not merged. AFAIK this series http://thread.gmane.org/gmane.comp.file-systems.btrfs/45237 will fix that, but it's scheduled for 4.2 .
Comment 4 Timo Kokkonen 2015-05-27 09:59:43 UTC
You are right. I see I had accidentally left Omar Sandoval's previous fix proposal on my tree and buried it with a merge. So that's why it didn't reproduce any more for me.

I'm reopening this bug so it reflects the current state. Sorry about the noise.
Comment 5 Raphaël Jakse 2018-09-07 08:19:44 UTC
Hello,

I just ran into this issue on Linux 4.17.8 and btrfs-progs v4.16.1.

btrfs subvolume delete @ is like rm -rf / on steroids, featuring "ls: command not found" and "Oh, well." way more efficiently.

A big advantage is, this "Why does this command takes several seconds to return? Oh f*" moment does not happen, and no scaring endless file listing is shown.

Note You need to log in before you can comment on or make changes to this bug.