[Users] discard support for SSD in OpenVZ kernel

[Kirill Korotaev]

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 <spameden at gmail.com>
 wrote:

> 
> 
> 
> 2013/8/29 Kirill Korotaev <dev at parallels.com>
> 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 <kir at openvz.org> wrote:
> 
>> On 08/28/2013 06:34 AM, spameden wrote:
>>> 
>>> 
>>> 
>>> 2013/8/28 Kir Kolyshkin <kir at openvz.org>
>>> 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
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20130829/10dd4892/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/users/attachments/20130829/10dd4892/attachment-0001.p7s>