$ sudo ./btrfs-debug-tree /dev/sdf3 | grep 58464632832
namelen 11 datalen 0 name: 58464632832
namelen 11 datalen 0 name: 58464632832
inode ref index 266598 namelen 11 name: 58464632832
Is that a real inode number? I think it isn't ... Wait -- I think I'm
picking a file in /tmp with that name, which is a block I dumped.
Renamed it.
$ sudo ./btrfs-debug-tree /dev/sdf3 | grep 58464632832
Now it returns nothing...
On Sat, Oct 11, 2014 at 1:52 AM, Liu Bo <bo.li.liu@xxxxxxxxxx> wrote:
> On Thu, Oct 09, 2014 at 09:58:03AM -0700, Rich Rauenzahn wrote:
>> On 10/9/2014 12:13 AM, Liu Bo wrote:
>> >sudo ./btrfs inspect-internal logical-resolve -v 58464632832 /
>>
>> $ sudo ./btrfs inspect-internal logical-resolve -v 58464632832 /
>> ioctl ret=0, total_size=4096, bytes_left=4080, bytes_missing=0,
>> cnt=0, missed=0
>
> Hi Rich,
>
> So cnt=0 is the reason that we got nothing output, however,
> to be honest, I don't know exactly why 'cnt' is 0, perhaps it's due to an old
> version btrfs, as the 'btrfs inspect-internal' command depends on ioctl which
> may have bugs in old btrfs.
>
>>
>> I also tried -P and -s 100000000 ....
>>
>> Also did this:
>>
>> $ sudo ./btrfs-map-logical -l 58464632832 -o /tmp/58464632832 /dev/sdf3
>> mirror 1 logical 58464632832 physical 1536393216 device /dev/sdg3
>> mirror 2 logical 58464632832 physical 58464632832 device /dev/sdf3
>>
>> And looked at the 4k block. strings doesn't show anything useful: +V0T"
>> File doesn't recognize it as anything particular.
>>
>> Weird.
>
> One ultimate solution is to use 'btrfs-debug-tree' to dump the human readable
> metadata information and grep for 58464632832 to read inode info. ,
> but this may cost time depending on the size of your patition.
>
> thanks,
> -liubo
>
>>
>> I have one other clue which I think is irrelevant. I had another
>> error on a different drive/different fs and it turned out to be the
>> vmem file for a virtual machine under vmware workstation. I deleted
>> the file since it was just the memory image and the error went away.
>> It was easy to map the bad block to the file from dmesg and the
>> inode. I may have also created a vm at some point on this drive
>> we're looking at now and then moved it. So I think that information
>> is not relevant... but maybe you've seen this before.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
