On 10/07/2014 03:19 PM, Chris Mason wrote:
> On Tue, Oct 7, 2014 at 1:25 AM, David Arendt <ad...@prnet.org> wrote:
>> I did a revert of this commit. After creating a snapshot, the
>> filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
>> seconds after mount without error message) . Maybe there was some
>> previous damage that just appeared now. This evening, I will restore
>> from backup and report back.
>> On October 7, 2014 12:22:11 AM CEST, Chris Mason <c...@fb.com> wrote:
>>> On Mon, Oct 6, 2014 at 4:51 PM, David Arendt <ad...@prnet.org> wrote:
>>>> I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
>>>> working without any problem. Afterwards I upgraded again to 3.17 and
>>>> problem reappeared. So the problem seems to be kernel version
>>> [ backref errors during btrfs-send ]
>>> Ok then, our list of suspects is pretty short. Can you easily build
>>> test kernels?
>>> I'd like to try reverting this commit:
> Oh no! Reverting this definitely should not have caused corruptions,
> so I think the problem was already there. Do you still have the
> filesystem image?
> Please let us know if you're missing files off the backup, we'll help
> pull them out.
> 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
Due to space constraints, it was not possible to take an image of the
corrupted filesystem. As I do backups daily, and the problems occurred 5
hours after backup, no file was lost. Thanks for offering your help. In
4 days I will do some send tests on the newly created filesystem and
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