Re: Fi corruption on RAID1, generation doesn't match

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

 



On 7 February 2016 at 20:56, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
>
> You are wondering why data is still 168G, but that's the allocated data
> chunk size.
>
> It means 168G space is allocated to store data, but only 42M is used.
> Matches with your vanilla df output.
>
> So it doesn't mean you data are still here.

I understand now. Thanks very much!


[...]
>
> That's the previous transaction's tree root.
> If you are in good luck, previous trans may has all your data.
> But if you are in bad luck, it may already after the remove.
>
> Normally, at least something should still be in previous trans.
>
> Now use btrfsck to check if previous trans is in good shape.
>
> # btrfsck --tree-root 647630028800
>
> If btrfsck only reports minor problems, like space cache tree mismatch, then
> it means previous trans are almost OK.
>
> Then let btrfsck to revert to previous trans:
>
> # btrfsck --tree-root 647630028800 --repair
>
> If you're really in good luck, then you can mount the fs and found something
> in it.


Great! I'll try this.

The 'tree-root' option must be a recent development. My 'stable'
Debian live disk does not recognize this option.

Could any one recommended a live disk that already includes this btrfsck option?

Many thanks!

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