On 07/03/2017 10:48 PM, Pete wrote: > 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...
Heh.. :) >> 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. Not really, it's halfway gone through the grinder already. Deleting a subvolume means looking at all the files that are in the filetree of that subvolume, looking at all extents they reference, and then for all of those extents lower reference counts, and free all space for extents that are not used by anyone else any more. If that's done, then removing the actual filesystem root object if it's held by some mount reference (as I imagine it would be) in the kernel is just the last straw. -- Hans van Kranenburg -- 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
