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.
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.
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.
Miao, as that was your patch, can you probably check if you can reproduce the
problem?
Thanks,
-Jan
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:
quoted
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