> You might try 'btrfs check' without repairing, using a recent version > of btrfs-progs and see if it finds anything unusual.
Not quite sure what that output means, but btrfs check returns instantly: $ sudo btrfs check /dev/mapper/think--big-home Checking filesystem on /dev/mapper/think--big-home UUID: 7f1ce0ed-5986-43ae-b0dd-727eee19fd08 checking extents checking free space cache checking fs roots checking csums checking root refs found 655360 bytes used err is 0 total csum bytes: 0 total tree bytes: 131072 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 123528 file data blocks allocated: 524288 referenced 524288 When I do the same thing on the root-OS partition that is on the same disk, it takes a bit longer to complete, and I'm getting: $ sudo btrfs check /dev/mapper/think--big-jessie Checking filesystem on /dev/mapper/think--big-jessie UUID: d82e2746-4164-41fa-b528-5a5838d818c6 checking extents checking free space cache checking fs roots checking csums checking root refs found 29295181824 bytes used err is 0 total csum bytes: 27623652 total tree bytes: 973848576 total fs tree bytes: 874446848 total extent tree bytes: 62554112 btree space waste bytes: 154131992 file data blocks allocated: 29202391040 referenced 30898016256 So I reckon the tree(s) in my home partition is just empty? Why would btrfs-find-tree take so long to complete though? Also, I've tried to run btrfs-find-tree on the root-OS partition, but that also didn't complete within the 10 minutes I tried (so far). > Although, are there many snapshots? That would cause the rentention of roots. I can't remember exactly, but it's very possible I didn't use any snapshots on this machine at all. -- 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
