On Sep 28, 2013, at 1:26 PM, Martin <m_bt...@ml1.co.uk> wrote: > Writing data via rsync at the 6Gbit/s sata rate caused > IO errors for just THREE sectors... > > Yet btrfsck bombs out with LOTs of errors…
Any fs will bomb out on write errors. > How best to recover from this? Why you're getting I/O errors at SATA 6Gbps link speed needs to be understood. Is it a bad cable? Bad SATA port? Drive or controller firmware bug? Or libata driver bug? > Lots of sata error noise omitted. And entire dmesg might still be useful. I don't know if the list will handle the whole dmesg in one email, but it's worth a shot (reply to an email in the thread, don't change the subject). It's possible software or hardware problems are detected well before writes are even initiated. > Running "badblocks" twice in succession (non-destructive data test!) > shows no surface errors and no further errors on the sata interface. SATA link speed related errors aren't related to bad blocks. If you do a smartctl -x on the drive, chances are it's recording PHY Event errors that might be relevant, and also SMART might record UDMA/CMC errors that would just corroborate that the drive also found link errors. > > Running btrfsck twice gives the same result, giving a failure with: Well honestly at this point I expect file system corruption as it's entirely possible that before the hardware dropped the link speed down to SATA 3Gbps, there was corrupt data already sent to the drive and that's not something Btrfs can know about until trying to read the data back in. So *shrug* - I don't see Btrfs as a way to totally mitigate hardware problems. It's the same problem with bad RAM, and Btrfs doesn't like that either. Chris Murphy -- 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
