On Wed, Sep 09, 2009 at 09:37:42AM +0100, Daniel J Blueman wrote: > >> > >> http://www.ocztechnologyforum.com/forum/showthread.php?t=57516 > > > > The issue is pretty much moot at this point, since OCZ support were not > > really interested in providing any sort of real technical support to > > find out what really caused this issue. My main worry was reliability of > > these cheaper SSD drives, and that worry is still not resolved. If you > > read the blog entries, I do comment on the apparently scary basic bugs > > taht are still being fixed on the Indilinx controllers. I do expect some > > basic level of data integrity from a consumer product and at least some > > interest in resolving weird corruption issues if things go wrong. Since > > OCZ cannot provide anything like that, I have a hard time recommending > > these drives for anything but very casual use. Fast, cheap, reliable. > > Pick any two. > > > > My drive was running 1.10 at the time of the problem. > > It looks like we need a small tool which performs patterned block I/O > to the device, updating a checksum as it goes, and performing > integrity sweeps at intervals, lower level than fsx. It must be > trusted or not. > > I had a problem like this with nVidia CK804/MCP55 chipsets corrupting > data under a triple-edge case workload. Well, just use git ;) Apply a bunch of patches (say the mm tree) with guilt and repack in a loop. -chris -- 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
