> On 07 Jul 2015, at 16:59, Heikki Linnakangas <hlinnaka@xxxxxx> wrote: > >> >> So it lies about fsync()... The next question is, does it nevertheless enforce the correct ordering of persisting fsync'd data? If you write to file A and fsync it, then write to another file B and fsync it too, is it guaranteed that if B is persisted, A is as well? Because if it isn't, you can end up with filesystem (or database) corruption anyway. On Tue, Jul 7, 2015 at 10:58 AM, Graeme B. Bell <graeme.bell@xxxxxxxx> wrote: > > Yikes. I would not be able to sleep tonight if it were not for the BBU cache in front of these disks... > > diskchecker.pl consistently reported several examples of corruption post-power-loss (usually 10 - 30 ) on unprotected M500s/M550s, so I think it's pretty much open to debate what types of madness and corruption you'll find if you look close enough. 100% agree with your sentiments. I do believe that there are other enterprise SSD vendors that offer reliable parts but not at the price point intel does for the cheaper drives. The consumer grade vendors are simply not trustworthy unless proven otherwise (I had my own unpleasant experience with OCZ for example). Intel played the same game with their early parts but have since become a model of how to ship drives to the market. RAID controllers are completely unnecessary for SSD as they currently exist. Software raid is superior in every way; the hardware features of raid controllers, BBU, write caching, and write consolidation are redundant to what the SSD themselves do (being themselves RAID 0 basically). A hypothetical SSD optimized raid controller is possible; it could do things like balance wear and optimize writes across multiple physical drives. This would require deep participation between the drive and the controller and FWICT no such things exists excepting super expensive sans which I don't recommend anyways. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
