On 2012-05-14, at 5:08 AM, David Sterba wrote:

On Wed, May 09, 2012 at 10:38:30AM -0700, Brendan Smithyman wrote:

quoted

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:

I've read again your first post and indeed it's not the empty subvol
issue.

quoted

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).

So I followed the steps to reproduce it with a 3.4 kernel, but I don't
see the duplicated @working anywhere.

# btrfs subvol create @working
# ls @working
src/
# btrfs subvol snap @working 2012-05-14
# btrfs subvol snap @working test
# ls test/
src/

# btrfs subvol list .
ID 258 top level 5 path @working
ID 259 top level 5 path 2012-05-14
ID 260 top level 5 path test

quoted

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.

Not a consistent behaviour then, so there's another factor.

Please run stat on the test/@working directory, if it's the ino == 2
(empty subvol) or not.

It is inode == 2.

Do you do lot's of snapshots on the fs, or are there lots of data plus
the filesystem is ~80% full? I have a theory, that this can somehow
interact with background subvolume deletion: if a subvolume is deleted
from directory hierarchy, but just scheduled for deletion, reusing it's
name could be incorrectly taken as part of the dir hierarchy to snapshot
and thus the extra '@working' is created.

Not a ton; I may have had half a dozen at one point while testing a backup script, but they were all essentially identical.  Probably < 10 in the history of the filesystem (it's quite new).  Data use is maybe 60% of the raw drive capacity IIRC; still lots of unallocated space for new chunks.

In your environment this would mean that there was a subvolume 'test',
then deleted, still in the queue for actual deletion. Slow snapshot
deletion may come from large number of them and this is even slower when
the filesystem is fragmented or near full.

quoted

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.

Seems more like a bug, let's narrow down the conditions before we look
into the code.

I just replied to your other email about the existing bug.

Thanks,
Brendan

thanks,
david