SSDSC2CW240A3 == Intel 520. It's not server grade as well and though it behaves much much better then desktop SSDs - we still saw it's loosing commits on power failure. So beware that your database can corrupt or loose transactions. All server grade SSDs from Intel have "Enhanced power-loss data protection" feature in specs which implies capacitors on the board for saving data to NVRAM. It's 320, 710 and S3700 models. Intel S3700 is the best and fastest we ever saw among different models including non-Intel ones and this is what Parallels recommends in Parallels Cloud Storage.
On Aug 29, 2013, at 13:20 , spameden <[email protected]> wrote: > > > > 2013/8/29 Kirill Korotaev <[email protected]> > I also want to add that SSD models referred to in the bug (like OCZ one) are > not server grade and you guys risk very much loosing your data or corrupting > file system on power failure. > You should test it heavily. > > Thanks for that. > > But we are not using OCZ (also know they are not reliable). > > The SSD in this server is INTEL SSDSC2CW240A3. > > I can't try the latest redhat kernel on this system, because after converting > it to deb it seems to be not working. > > But I believe fix should be in 2.6.32-358.18.1.el6.centos.plus.x86_64. > > On Aug 29, 2013, at 03:52 , Kir Kolyshkin <[email protected]> wrote: > >> On 08/28/2013 06:34 AM, spameden wrote: >>> >>> >>> >>> 2013/8/28 Kir Kolyshkin <[email protected]> >>> On 08/27/2013 08:20 AM, spameden wrote: >>>> ArchLinux wiki says: >>>> Warning: Users need to be certain that kernel version 2.6.33 or above is >>>> being used AND that their SSD supports TRIM before attempting to mount a >>>> partition with the discard flag. Data loss can occur otherwise! >>>> >>>> So I guess it's not in the OpenVZ kernel? >>>> >>>> I'd like to use TRIM because it increases performance to SSD drastically! >>> >>> You'd better check it with Red Hat, looking into their RHEL6 documentation. >>> >>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel >>> do support trim, they have backported it (as well as tons of other stuff, >>> so this is hardly 2.6.32 kernel anymore). >>> >>> I've just tested via hdparm (ofc it's not a perfect tool to test out disk >>> performance but still), here is what I get on the latest >>> 2.6.32-042stab079.5: >>> >>> # hdparm -t /dev/mapper/vg-root >>> /dev/mapper/vg-root: >>> Timing buffered disk reads: 828 MB in 3.00 seconds = 275.56 MB/sec >>> >>> on standard debian-7 kernel (3.2.0-4-amd64): >>> # hdparm -t /dev/mapper/vg-root >>> /dev/mapper/vg-root: >>> Timing buffered disk reads: 1144 MB in 3.00 seconds = 381.15 MB/sec >>> >>> and it's only read speed test. >>> >>> I don't get why it differs so much? >>> >> >> My suggestion is, since this functionality is not directly related to >> OpenVZ, and >> we usually don't change anything in this code (unless there is a reason to), >> to >> try reproducing it on a stock RHEL6 kernel and, if it is reproducible, file >> a bug >> to red hat or, if it's not reproducible, file a bug to openvz. >> >> Kir. >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.openvz.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
