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 <[email protected]> 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 <[email protected]> > >> >> >> >> 2013/8/29 Kirill Korotaev <[email protected]> >> >>> 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 <[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 >>> >>> >>> >>> _______________________________________________ >>> 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
