>> Of course it could just be a bug so it's worth trying David's integration branch. > >I'll try that shortly. > >> * Firmware Version: 0006 >> >> Firmware 0007 is current for this SSD. > >I assume that's probably not something I should mess with right now though, right? > >> 6 0x008 4 9821 Number of Hardware Resets >> >> Why is the hardware being reset so many times? > >What exactly is that stat measuring? This is a 3 year old laptop with >a 3 year old SSD. The whole system certainly gets restarted more often >than a desktop or server would, but not an average of 9 times a day. >Probably not even a maximum of 9 times a day. Could that reset be >something related to acpi? Actually, now that I think about it, that may be related to the errors I saw months ago. I had some bad blocks or something, and when the system attempted to access them I would get a bunch of errors in the logs. I believe one of the things the system would do was attempt to reset the drive connection (maybe multiple times). So that could have driven that number up substantially. The "Lifetime Power-On Resets" is only 1033, which seems about right for the age of the drive. I zeroed out the drive and ran every smartctl test on it I could find and it never threw any more errors. I really pounded it, a good solid week or so of scans and data writes. Finally decided that perhaps those blocks went bad but didn't get properly marked as bad and removed from active duty until I zeroed everything out. Whatever the underlying issue was this time, I don't think it's exactly the same, because in that previous scenario the problem blocks would consistently throw errors. I couldn't get a clean dd image of the drive. I had to use ddrescue and live with a few small gaps. But I was still able to mount that rescued image (it was ext4) and get pretty much all of the data back. This time I'm encountering no read errors at the drive level and had no trouble creating the dd image. I'll see if I can track down any of the smartctl results from back then and compare the "Number of Hardware Resets" value, as well as UDMA_CRC_Error_Count. -- 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
