Thanks David, If I understand you correctly, this would be the case with nested subvolumes; i.e., if subvolume A is exists within the directory tree subvolume B, and B is snapshotted. I expected this, and it sounds totally consistent with my understanding of how btrfs subvolumes work. However, the behaviour I'm seeing seems to be a different thing, so I just want to double-check:
In my case I am executing the "btrfs subvolume snapshot @working newsnapshot" command (or something like it). The "@working" subvolume exists in the filesystem root, and does not contain any other subvolumes within its own subdirectory tree. In the new subvolume, "newsnapshot", there is an entry called "@working" that is identified as inode number 2 as you say. But this isn't due to a subvolume in the directory tree of the original "@working", since it still happens, e.g., if it is the only subvolume on the system (apart from the root, of course). The naive assumption is that (excepting nested subvolumes), the snapshot should be indistinguishable from the original. Additionally, I'm a bit perplexed by the behaviour on some of my volumes and not others. It's not a big deal, and I'm happy to take your word for it (or look at the code, if you'd be willing to point me in the right direction; I'm not averse to learning). I just wanted to double-check that we're talking about the same thing. I appreciate the help! Cheers, Brendan On 2012-05-09, at 9:58 AM, David Sterba wrote: > On Mon, May 07, 2012 at 05:10:08PM -0700, Brendan Smithyman wrote: >> I'm experiencing some odd-seeming behaviour with btrfs on Ubuntu >> 12.04, using the Ubuntu x86-64 generic 3.2.0-24 kernel and btrfs-tools >> 0.19+20120328-1~precise1 (backported from the current Debian version >> using Ubuntu's backportpackage). When I snapshot a subvolume on some >> of my drives, it creates an empty directory inside the snapshot with >> the same name as the original subvolume. Example case and details >> below: > > This is known and it's not a problem, though I was surprised when I had > first seen it myself. Snapshotting is not recursive, the case of > file->file, directory->directory is straightforward, and when a > subvolume is encountered, a new file sub-type is created, it's > identified by BTRFS_EMPTY_SUBVOL_DIR_OBJECTID internally, so it's a kind > of a "stub" subvolume. It is identified by inode number 2 in stat > output. The object cannot be modified and just sits there. > > > david
smime.p7s
Description: S/MIME cryptographic signature
