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

Fri Apr 6 14:41:00 EDT 2012

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openvz.org/pipermail/users/attachments/20120406/3d1f549f/attachment.html