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

[Kirill Korotaev]

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>