On 11/12/2015 15:21, Laurent Bonnaud wrote:
> The next step will we to run a "btrfs scrub" to check if data loss did
> happen...
Scrubbing is now finished and it detected no errors.
--
Laurent.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
On 04/12/2015 01:47, Qu Wenruo wrote:
> [run btrfsck]
I did that, too with an old btrfsck version (4.0) and it found the following
errors.
Then I did a btrfsck --repair, and I have been able to complete my "du -s" test.
The next step will we to run a "btrfs scrub" to check if data loss did
On 04/12/2015 01:47, Qu Wenruo wrote:
> The chunk mismatch problem should be resolved already, as the patch is merged
> in david's devel branch.
Great ! I am looking forward to a new release with this bug fix...
> But for the kernel abort transaction, I'm sorry there is no good clue yet.
>
On 25/11/2015 10:05, Laurent Bonnaud wrote:
>> > Nice reproducer.
>> > Is it 100% reproducible or has a chance to reproduce?
> I tried a second time and got a similar kernel backtrace.
Hi,
any news since you downloaded my FS image ?
I kept my corrupted FS in case
On 25/11/2015 00:46, Qu Wenruo wrote:
> The size seems small enough, I'll try to download it as it's super useful to
> debug it.
Thanks !
> Nice reproducer.
> Is it 100% reproducible or has a chance to reproduce?
I tried a second time and got a similar kernel backtrace.
> BTW, did you
On 23/11/2015 02:00, Qu Wenruo wrote:
> Considering the size, I'd like not to touch the dump, metadata is over 5G,
It is only 2GB once compressed :>.
> and I think it's not related to on-disk data, but runtime problem like I
> mentioned above.
To test this hypothesis I did the following:
-
On 22/11/2015 03:04, Qu Wenruo wrote:
> If any of you can recompile btrfs-progs and use gdb to debug it,
> would anyone please to investigate where did the wrong_chunk_type is
> set?
In the mean time my btrfs filesystem degraded
Nov 20 18:10:53 irancy kernel: BTRFS: device label sauvegarde-IUT2
