[Users] discard support for SSD in OpenVZ kernel

LightDot lightdot at gmail.com
Fri Aug 30 12:21:51 EDT 2013


Looking at the CentOS's bugzilla, this issue hasn't even been reported to
Red Hat yet.

When/if this changes get ito the RHEL's stock kernel, it will get into
OpenVZ's RHEL kernel too.


On Thu, Aug 29, 2013 at 1:19 PM, spameden <spameden at gmail.com> wrote:

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20130830/0e1c6db9/attachment.html>


More information about the Users mailing list