Btrfs-progs: filter the deleted subvolumes when listing snapshots
authorWang Shilong <wangsl-fnst@cn.fujistu.com>
Fri, 1 Feb 2013 07:56:29 +0000 (15:56 +0800)
committerDavid Sterba <dsterba@suse.cz>
Fri, 1 Feb 2013 15:55:06 +0000 (16:55 +0100)
commit64edc851da59c47b92ee6830101be0854add7f09
treea17ce384c32fcd98e03b33c0c515ac5371c3f987
parent437eea9664ce5f1782aee43f0f8cc49a3e40e9f0
Btrfs-progs: filter the deleted subvolumes when listing snapshots

btrfs snapshot list command will stop by the deleted subvolumes.

The problem may happen by two ways:
1. a subvolume deletion is not commited, that is ROOT_BACKREF has been deleted,
   but ROOT_ITEM still exists. The command will fail to fill the path of
   the deleted subvolumes because we can not get the parent fs/file tree.
2. a subvolume is possibly deleted when we fill the path, For example,
   Fs tree
     |->subv0
  |->subv1

   We may fill the path of subv1 firstly, after that, some user deletes subv1
   and subv0, and then we fill the path of subv0. The command will fail to
   fill the path of subv0 because we can not get path of subv0. And the command
   also will fail to make the full path of subv1 because we don't have the path
   of subv0.

Since these subvolumes have been deleted, we should filter them. This patch
fixed the above problem by this way.

For the 1st case, ->ref_tree of the deleted subvolumes are 0.
For the 2nd case, if we found the error number that ioctl() returns is ENOENT,
we will set ->ref_tree to 0.
And when we make the full path of the subvolumes, we will check ->ref_tree of
them and their parent. If someone's ->ref_tree or its parent's ->ref_tree is 0,
we will filter it.

Reported-by: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs-list.c