Ok, I did nuke it now and created the fs again using 3.12 kernel. So far so good. Runs fine. Finally, I know its kind of offtopic, but can some help me interpreting this (I think this is the error in the smart-log which started the whole mess)? Error 1 occurred at disk power-on lifetime: 2576 hours (107 days + 8 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 71 00 ff ff ff 0f Device Fault; Error: ABRT at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 61 00 08 ff ff ff 4f 00 5d+04:53:11.169 WRITE FPDMA QUEUED 61 00 08 80 18 00 40 00 5d+04:52:45.129 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 5d+04:52:44.701 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 5d+04:52:44.700 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 5d+04:52:44.679 WRITE FPDMA QUEUED 2014-02-07 Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > > On Feb 7, 2014, at 4:34 AM, Johan Kröckel <johan.kroeckel@xxxxxxxxx> wrote: > >> Is there anything else I should do with this setup or may I nuke the >> two partitions and reuse them? > > Well I'm pretty sure once you run 'btrfs check --repair' that you've hit the end of the road. Possibly btrfs restore can still extract some files, it might be worth testing whether that works. > > Otherwise blow it away. I'd say test with 3.14-rc2 with a new file system and see if you can reproduce the sequence that caused this problem in the first place. If it's reproducible, I think there's a bug here somewhere. > > > Chris Murphy -- 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
