On 07/03/2017 12:30 AM, Hans van Kranenburg wrote: > On 07/02/2017 11:33 PM, Pete wrote: >> I found that I can delete a mounted subvolume using: >> btrfs subvolume delete <mounted sub volume> >> >> This works. Is this the intended action? To me it would seem like a >> warning and the command exiting would make sense? > > Yes, you can do that. It's a bit similar to the fact that you can also > delete a regular file when it's still open by another program. I was expecting it to behave somewhat like trying to unmount an active filesystem, where you are prevented from doing so. Aside: the way I found out was that the backup script I was writing, rather than deleting the read only snapshots deleted the source subvolumes, nearly everything on the system apart from the snapshots... > But, still having a file open (inode, filedescriptor, what's it > called...) does actually block the cleaner process from progressing > beyond that point. > > You can also delete a subvolume which is not separately mounted, while a > process still has open files in it. > You'd have to do that from within the mounted parent subvolume, I think, so that looks more normal? > In case of deleting a mounted subvolume... it's a bit different. As long > as it's mounted, even if nothing else is using a file within, it won't > be actually completely deleted in the background, unless the final > umount is done. What can happen (I just tried it) is that the mount > point ends up looking completely empty already in the meantime, as soon > as no files are open and after I cd .. out of it. If I cd back into the > mount point, there's nothing any more and any action to create something > new within will end up with a "No such file or directory". > > Only when doing the umount, the subvolume completely disappears. > So provided I did not unmount the deleted subvols then I could actually have undeleted them? Of does that require developer level skills? Too late now, and I recovered from snapshots and a little data from the backup drive. Also I'd think dangerous to offer this option as people might assume they could rely on it which might be a dangerous assumption. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
