[Users] discard support for SSD in OpenVZ kernel

[spameden]

Hi

The problem seems to be fixed in 2.6.32-358.18.1.el6.centos.plus.x86_64

Finally found how to install it properly on Debian 7.

Here is results:
# hdparm -t /dev/mapper/vg-root

/dev/mapper/vg-root:
 Timing buffered disk reads: 992 MB in  3.00 seconds = 330.13 MB/sec


Much better as you can see.

How long it would take to get that fix into OpenVZ kernel?

Bug link: http://bugs.centos.org/view.php?id=6548

Kernel:
http://ftp.tu-chemnitz.de/pub/linux/centos/6.4/centosplus/x86_64/Packages/kernel-2.6.32-358.18.1.el6.centos.plus.x86_64.rpm


2013/8/29 spameden <spameden at gmail.com>

>
>
>
> 2013/8/29 Kirill Korotaev <dev at parallels.com>
>
>> 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.
>>
>
> Ofc it's not that good, but we can't offer right now to buy overpriced
> hardware (for us, at least).
>
> Our database is XtraDB and it's commiting every second.
>
> Losing 1 second of transactions is not a problem for us.
>
> However, slow speed with 2.6.32 openvz kernel is a problem. As you can see
> there is a problem on this particular kernel.
>
> I'll try to investigate more and report back.
>
>>
>>
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/d413d5f6/attachment-0001.html>