[Users] Re: [Announce] Kernel RHEL6 testing 042stab054.1

Fri Apr 6 16:49:45 EDT 2012

This probably means your /vz partition has less space than the limit you
set. There's an article on wiki explaining that in details, let me see...
right,  http://wiki.openvz.org/Disk_quota,_df_and_stat_weird_behaviour
06.04.2012 22:44 пользователь "jjs - mainphrame" <jjs at mainphrame.com>
написал:

> Something definitely weird happening with simfs file sizes now:
>
> [root at mrmber ~]# vzctl set 777 --save --diskspace="20000000:24000000"
> CT configuration saved to /etc/vz/conf/777.conf
> [root at mrmber ~]# vzctl exec 777 df
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/simfs             5474372    710700   3205452  19% /
> none                    131072         4    131068   1% /dev
> [root at mrmber ~]#
>
> ploop-based CTs seem fine.
>
> Joe
>
> On Thu, Apr 5, 2012 at 11:24 PM, jjs - mainphrame <jjs at mainphrame.com>wrote:
>
>> Look closer - there is breakage here. Normally there was a 10% difference
>> between simfs and ploop, but this is different - this simfs CT has only 1/3
>> the advertised disk space...
>>
>> Joe
>>
>>
>> On Thu, Apr 5, 2012 at 11:06 PM, Kirill Korotaev <dev at parallels.com>wrote:
>>
>>> Note, that ploop contains ext4 inode tables also (which are preallocated
>>> by ext4), so ext4 reserves some space for its own needs.
>>> Simfs however was limiting *pure* file space.
>>>
>>> Kirill
>>>
>>> On Apr 6, 2012, at 04:58 , jjs - mainphrame wrote:
>>>
>>> > However I am seeing an issue with the disk size inside the simfs-based
>>> CT.
>>> >
>>> > In the vz conf files, all 3 CTs have the same diskspace setting:
>>> >
>>> > [root at mrmber ~]# grep -i diskspace /etc/vz/conf/77*conf
>>> > /etc/vz/conf/771.conf:DISKSPACE="20000000:24000000"
>>> > /etc/vz/conf/773.conf:DISKSPACE="20000000:24000000"
>>> > /etc/vz/conf/775.conf:DISKSPACE="20000000:24000000"
>>> >
>>> > But in the actual CTs the one on simfs reports a significantly smaller
>>> disk space than it did under previous kernels:
>>> >
>>> > [root at mrmber ~]# for i in `vzlist -1`; do echo $i; vzctl exec $i df;
>>> done
>>> > 771
>>> > Filesystem           1K-blocks      Used Available Use% Mounted on
>>> > /dev/ploop0p1         23621500    939240  21482340   5% /
>>> > none                    262144         4    262140   1% /dev
>>> > 773
>>> > Filesystem           1K-blocks      Used Available Use% Mounted on
>>> > /dev/simfs             6216340    739656   3918464  16% /
>>> > none                    262144         4    262140   1% /dev
>>> > 775
>>> > Filesystem           1K-blocks      Used Available Use% Mounted on
>>> > /dev/ploop1p1         23628616    727664  21700952   4% /
>>> > none                    262144         4    262140   1% /dev
>>> > [root at mrmber ~]#
>>> >
>>> > Looking in dmesg shows this:
>>> >
>>> > [ 2864.563423] CT: 773: started
>>> > [ 2866.203628] device veth773.0 entered promiscuous mode
>>> > [ 2866.203719] br0: port 3(veth773.0) entering learning state
>>> > [ 2868.302300]  ploop1:
>>> > [ 2868.329086] GPT:Primary header thinks Alt. header is not at the end
>>> of the disk.
>>> > [ 2868.329099] GPT:47999999 != 48001023
>>> > [ 2868.329104] GPT:Alternate GPT header not at the end of the disk.
>>> > [ 2868.329111] GPT:47999999 != 48001023
>>> > [ 2868.329115] GPT: Use GNU Parted to correct GPT errors.
>>> > [ 2868.329128]  p1
>>> > [ 2868.333608]  ploop1:
>>> > [ 2868.337235] GPT:Primary header thinks Alt. header is not at the end
>>> of the disk.
>>> > [ 2868.337247] GPT:47999999 != 48001023
>>> > [ 2868.337252] GPT:Alternate GPT header not at the end of the disk.
>>> > [ 2868.337258] GPT:47999999 != 48001023
>>> > [ 2868.337262] GPT: Use GNU Parted to correct GPT errors.
>>> >
>>> > I'm assuming that this disk damage occurred under the buggy stab54.1
>>> kernel. I could destroy the container and create a replacement but I'd like
>>> to make believe, for the time being, that it's valuable. Just out of
>>> curiosity, what tools exist to fix this sort of thing? The log entries
>>> recommend gparted, but I suspect I may not have much luck from inside the
>>> CT with that. If this were PVC, there would obviously be more choices. You
>>> thoughts?
>>> >
>>> > Joe
>>> >
>>> > On Thu, Apr 5, 2012 at 3:17 PM, jjs - mainphrame <jjs at mainphrame.com>
>>> wrote:
>>> > I'm happy to report that stab54.2 fixes the kernel panics I was seeing
>>> in stab54.1 -
>>> >
>>> > Thanks for the serial console reminder, I'll work on setting that up...
>>> >
>>> > Joe
>>> >
>>> > On Thu, Apr 5, 2012 at 3:47 AM, Kir Kolyshkin <kir at openvz.org> wrote:
>>> > On 04/05/2012 08:48 AM, jjs - mainphrame wrote:
>>> > Kernel stab53.5 was very stable for me under heavy load but with
>>> stab54.1 I'm seeing hard lockups - the Alt-Sysrq keys don't work, only the
>>> power or reset button will do the trick.
>>> >
>>> > I don't have a serial console set up so I'm not able to capture the
>>> kernel panic message and backtrace. I think I'll need to get that set up in
>>> order to go any further with this.
>>> >
>>> >  054.2 might fix the issue you are having. It is being uploaded at the
>>> moment...
>>> >
>>> > Anyway, it's a good idea to have serial console set up. It greatly
>>> improves chances to resolve kernel bugs.
>>> http://wiki.openvz.org/Remote_console_setup just in case.
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at openvz.org
>>> > https://openvz.org/mailman/listinfo/users
>>> >
>>> >
>>> > <ATT00001.c>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org
>>> https://openvz.org/mailman/listinfo/users
>>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openvz.org/pipermail/users/attachments/20120407/c0d39f2b/attachment-0001.html