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 <[email protected]> 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@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@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@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 <[email protected]> > 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 <[email protected]> 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 > > [email protected] > > https://openvz.org/mailman/listinfo/users > > > > > > <ATT00001.c> > > > _______________________________________________ > Users mailing list > [email protected] > https://openvz.org/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] https://openvz.org/mailman/listinfo/users
