> Don't do it --- disks have cache and reading from the cache is as fast as > reading from SSD (or even faster), so if there is some speed-race in the > chip, there is a possibility that the data corruption happens with disks > too --- just with lower probability. > > If we don't know why the chip corrupts data, we must treat it as always > corrupting data. In which case we should delete the driver because serializing it is probably not sufficient. There is a proper way to deal with IDE problems and randomly turning things on and off isn't the solution from experience. So - It would be useful to get the data sheet that Daniela refers to - If there is some kind of data path issue then serializing probably isn't enough on its own as has been said and we need to understand why the libata case doesn't show corruption but clearly shows it is unhappy. Libata doesn't serialize the device and doesn't do fancy IRQ checking either. Just serializing is likely to make it worse - it may well become a rare deeply obscure corruption rather than a nice visible one like we have now - and that is far far nastier. Most likely libata also needs work. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
