Re: kernel BUG at fs/btrfs/volumes.c:3707 still not fixed in 3.7.1 (btrfs-zero-log required) but shown as "RIP btrfs_num_copies"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 12, 2013 at 07:12:12PM -0800, Marc MERLIN wrote:
> On Fri, Jan 11, 2013 at 09:49:52AM -0500, Josef Bacik wrote:
> > Probably just related to whatever corruption it is you are seeing.
>  
> So I have no corruption afterall, correct?
> 
> That's good news, but then it does mean that unclean sudden shutdowns in the wrong place.
> 
> I still have a truncated fs_image if someone wants it, and with an
> apparently uncorrupted FS, btrfs-image is still dying for me:
> andalfthegreat:~# btrfs-image -c 9 /dev/mapper/cryptroot  /var/tmp/fs_image2
> Check tree block failed, want=4261896192, have=10797364022063960087
> Check tree block failed, want=4261896192, have=10797364022063960087
> Check tree block failed, want=4261896192, have=13996544474027288730
> Check tree block failed, want=4261896192, have=10797364022063960087
> Check tree block failed, want=4261896192, have=10797364022063960087

want= are around 4G, have= numbers are way off, very likely a
corruption. the number does not translate into a meaningful pattern.

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


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux