> On 07 Jul 2015, at 16:59, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
>>
>> So it lies about fsync()... The next question is, does it nevertheless enforce the correct ordering of persisting
fsync'ddata? If you write to file A and fsync it, then write to another file B and fsync it too, is it guaranteed that
ifB 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@nibio.no> 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
closeenough.
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
