On Thu, 15 Nov 2012 17:05:41 +0100, Jan Schmidt wrote:
On Wed, November 14, 2012 at 19:26 (+0100), Jérôme Poulin wrote:
Using Debian experimental kernel, 3.6.4-1~experimental.1, and latest
btrfs tools from git master, I am not able to execute btrfs subvolume
list.
# ./btrfs sub li /mnt/data0/
ERROR: Failed to lookup path for root 0 - No such file or directory
After bisecting with git, I was able to confirm that commit
162df1e30c7c0492ae9fb551d74452e643f5fea2 breaks btrfs subvolume list
on my current kernel.
I can confirm this. Steps to reproduce:
- create subvolume
- put some data in
- delete subvolume
- call btrfs subvol list immediately
If you give it some time, listing of subvolumes eventually works. Calling
sync
doesn't help, surprisingly, while umount/mount does.
When we delete a subvolume, we just delete its ref and backref, don't delete
the tree
at once, it will be done by the cleaner thread, which is woke up after the
transaction
thread commits a transaction, that is the deletion of the tree may not be done
in the
current transaction. It is the reason why sync doesn't help.
Some add_root get's called with ref_tree = 0, which in turn makes
lookup_ino_path call BTRFS_IOC_INO_LOOKUP with a treeid of 0, which looks
wrong
to me. I haven't looked any closer.
Right.
Miao, as that was your patch, can you probably check if you can reproduce the
problem?
This problem was fixed by the following patch several days ago, but the patch
have not
been applied into Chris's btrfs-progs tree.
Btrfs-progs: filter the deleted subvolumes when listing snapshots
You can pull it from the URL:
git://github.com/miaoxie/btrfs-progs.git master
Thanks
Miao
--
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
