On Mon, Aug 3, 2015 at 4:22 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
> Yes, you're right, that's a dead loop.
>
> But for better debugging, would you please upload the following info?
> 1) output of command "btrfs-debug-tree -t 5 <DEV>".
> The only important things are info about that inode.
> Whose objectid(first item in a key) is 14214570 and type is one of the
> following:
> INODE_ITEM, INODE_REF, EXTENT_DATA
> So you may only need to cut the things like below:
> ======
>         item 4 key (14214570 INODE_ITEM 0) itemoff 15881 itemsize 160
>                 inode generation 6 transid 6 size 1073741824 nbytes
> 1073741824
>                 block group 0 mode 100644 links 1 uid 0 gid 0
>                 rdev 0 flags 0x0
>         item 5 key (14214570 INODE_REF XXX) itemoff 15866 itemsize 15
>                 inode ref index 2 namelen 5 name: file1
>         item 6 key (14214570 EXTENT_DATA 0) itemoff 15813 itemsize 53
>                 extent data disk byte 2176843776 nr 134217728
>                 extent data offset 0 nr 134217728 ram 134217728
>                 extent compression 0
>         item 7 key (14214570 EXTENT_DATA XXX) itemoff 15760 itemsize 53
>                 extent data disk byte 2311061504 nr 134217728
>                 extent data offset 0 nr 134217728 ram 134217728
>                 extent compression 0
>         ....(All items with 14214570 objectid is needed to debug)
> ======
>
> And it's highly recommended to only cut that part and paste it.
> Not only to reduce the output, but also help your privacy.
> As you can see, INODE_REF contains file name, which can be sometimes leaking
> your personal infomation.

        item 46 key (14214570 INODE_ITEM 0) itemoff 11902 itemsize 160
                inode generation 2285 transid 2308 size 32768 nbytes 0
                block group 0 mode 100644 links 1 uid 1000 gid 100
                rdev 0 flags 0x10
        item 47 key (14214570 INODE_REF 5506079) itemoff 11875 itemsize 27
                inode ref index 300 namelen 17 name: root-0bc95412.log


I double-checked and there is no EXTENT_DATA entry.

>
> 2) output of command "btrfs-debug-tree -t 2 <DEV>"
> Just in case your extent tree mismatch with fs tree.

The gzipped log is 13MB, so I've uploaded it to
https://dl.dropboxusercontent.com/u/3160732/btrfs-debug-tree-t-2.log.gz
; sha1sum is fb4c671bb90b97aa64f6d3938948100c2175e6a5 .

>
> If you don't like to execute 2 commands and are OK with leaking file/dir
> names, you can also use "btrfs-debug-tree <DEV>" to dump every metadata
> info.

If the above aren't enough I will provide the more comprehensive output.

>
> Alternatively, if "btrfs-image -c9 <DEV>" works without problem, it will
> also helps a lot for debugging.

This one is also quite large ( 332MB ) ->
https://dl.dropboxusercontent.com/u/3160732/sda1-btrfs-image-c9.img ;
sha1sum is c243e127a317f69faa5548993914a678f6f79524.

Thanks,

Robert
--
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

Reply via email to