Re: [Users] Ploop conversion (Error in tune_fs - can't set reserved blocks)
Out of curiosity, is Ploop 1.12.1 going to be released soon in the OpenVZ Yum repo? And here we are: From: Kir Kolyshkin k...@openvz.org Date: 3 September 2014 3:07:52 AM AWST To: annou...@openvz.org Subject: [Announce] ploop 1.12.1 OpenVZ project has released a new ploop version. Thanks a lot guys! Corrado ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Ploop conversion (Error in tune_fs - can't set reserved blocks)
Hi Kir, thanks for your response. Out of curiosity, is Ploop 1.12.1 going to be released soon in the OpenVZ Yum repo? Thanks, Corrado ___ On 13/08/2014, at 6:03 AM, Kir Kolyshkin wrote: In fact, this is caused by a stupid bug in ploop 1.12 (and older kernel). To workaround, install a new kernel (042stab092.x). Fixed in git: http://git.openvz.org/?p=ploop;a=commit;h=7e0365c0f8f Will appear in ploop 1.12 (most probably 1.12.1). Kir On 08/08/2014 12:12 AM, Corrado Fiore wrote: Dear All, today, during the conversion of a container to Ploop storage, I encountered some issues. My host is a CentOS box (2.6.32-042stab081.3) with the latest ploop and ploop-lib installed (1.12-1). When I issued the usual command `vzctl convert NNN`, the conversion process started but towards the end it printed: Error in tune_fs (fsutils.c:180): Can't set reserved blocks to 668415: Inappropriate ioctl for device I could start the CT and enter it. However, df -h was showing weird values (0 bytes available): # df -h Filesystem Size Used Avail Use% Mounted on /dev/ploop44599p1 52G 1.4G 0 100% / none 512M 4.0K 512M 1% /dev none 512M 0 512M 0% /dev/shm In fact, applications like Nginx believed that there was no space available and refused to write logs for example. But I was able to create a new file with the Nano editor. I tried the following to rectify the situation, without success: 1) `vzctl set NNN --disk MMMG --save`, with various values of MMM 2) deleting the INODES settings from the CT conf file and restarting 3) `tune2fs -m 5 /dev/ploop53231p1` In the end, I decided to just create a new container on a different host machine and transfer all application data from the latest backup (which I did minutes before issuing the conversion). Can you give me any clues about what happened? Thanks, Corrado Fiore ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Ploop conversion (Error in tune_fs - can't set reserved blocks)
In fact, this is caused by a stupid bug in ploop 1.12 (and older kernel). To workaround, install a new kernel (042stab092.x). Fixed in git: http://git.openvz.org/?p=ploop;a=commit;h=7e0365c0f8f Will appear in ploop 1.12 (most probably 1.12.1). Kir On 08/08/2014 12:12 AM, Corrado Fiore wrote: Dear All, today, during the conversion of a container to Ploop storage, I encountered some issues. My host is a CentOS box (2.6.32-042stab081.3) with the latest ploop and ploop-lib installed (1.12-1). When I issued the usual command `vzctl convert NNN`, the conversion process started but towards the end it printed: Error in tune_fs (fsutils.c:180): Can't set reserved blocks to 668415: Inappropriate ioctl for device I could start the CT and enter it. However, df -h was showing weird values (0 bytes available): # df -h Filesystem Size Used Avail Use% Mounted on /dev/ploop44599p1 52G 1.4G 0 100% / none 512M 4.0K 512M 1% /dev none 512M 0 512M 0% /dev/shm In fact, applications like Nginx believed that there was no space available and refused to write logs for example. But I was able to create a new file with the Nano editor. I tried the following to rectify the situation, without success: 1) `vzctl set NNN --disk MMMG --save`, with various values of MMM 2) deleting the INODES settings from the CT conf file and restarting 3) `tune2fs -m 5 /dev/ploop53231p1` In the end, I decided to just create a new container on a different host machine and transfer all application data from the latest backup (which I did minutes before issuing the conversion). Can you give me any clues about what happened? Thanks, Corrado Fiore ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
