From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZztS-0004U6-6I for qemu-devel@nongnu.org; Wed, 08 May 2013 04:38:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZztN-0001O1-Tu for qemu-devel@nongnu.org; Wed, 08 May 2013 04:38:34 -0400 Received: from [222.73.24.84] (port=32686 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZztN-0001Mq-J7 for qemu-devel@nongnu.org; Wed, 08 May 2013 04:38:29 -0400 Message-ID: <518A0E85.8010902@cn.fujitsu.com> Date: Wed, 08 May 2013 16:36:21 +0800 From: yuxh MIME-Version: 1.0 References: <5189E019.1090702@cn.fujitsu.com> <20130508063656.GA2766@fam-laptop.nay.redhat.com> <5189FFEF.3080202@cn.fujitsu.com> <20130508082025.GA13277@fam-laptop.nay.redhat.com> In-Reply-To: <20130508082025.GA13277@fam-laptop.nay.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] qemu-img problem when create a file larger than fs's size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org On 05/08/2013 04:20 PM, Fam Zheng wrote: > On Wed, 05/08 15:34, yuxh wrote: >> >> Thank you for your reply. I agreed what you said. >> And do you think we shall print a prompt to user when the size user >> specified is larger than available space ? > > Might be nice, but it's hard to define "available space", and "available > space" at creating time promises nothing. Even if the user creates a > small image which seems safe, risk is still there: when other > applications' data fills up the "available space", the use still > experiences the same problem. > Yes. That means the prompt means nothing. Thank you very much! yuxh >> >> On 05/08/2013 02:36 PM, Fam Zheng wrote: >>> I think it's the system admin to be responsible for the risk of over >>> provisioning. We have host sparse file[1] (as your example) for >>> preallocated image (for example, -f raw), as well as sparse image (as >>> supported in qcow2, vmdk, etc.). There are cases that host file system >>> is extended or the vm disk is moved to a larger storage when the actual >>> data grows closer to full, so it's not very practical to limit the >>> creating size, just as this is quietly valid in linux, no matter how >>> small your /tmp is. >>> >>> # df /tmp/ -h >>> Filesystem Size Used Avail Use% Mounted on >>> tmpfs 3.8G 14M 3.8G 1% /tmp >>> # touch /tmp/a >>> # truncate /tmp/a --size 10000T >>> # ls -l /tmp/a >>> -rw-rw-r--. 1 fam fam 10995116277760000 May 8 14:33 /tmp/a >>> >>> [1]: http://en.wikipedia.org/wiki/Sparse=5Ffile >>> >>> On Wed, 05/08 13:18, yuxh wrote: >>>> Hello all, >>>> >>>> I have to consult you a qemu-img's problem. >>>> >>>> Is this reasonable to create a file which is larger than the >>>> available size of the fs by qemu-img cmd ? >>>> >>>> When I use qemu-img create a file which is larger than the available >>>> size of the fs, the creation is completed succesfully. >>>> >>>> However when I use this file in guest as a guest's disk, and write >>>> beyond the size the host file can provides, the guest was paused by >>>> qemu-kvm or libvirt and was in maybe a infinite circle where the >>>> guest just can't be used except I detach the disk from guest or >>>> destroy the guest. >>>> >>>> I read the qemu-img's code and found it just create the file as we >>>> required and doesn't check if the size we specify is reasonable.But >>>> this may let the guest in a risk of meeting the problem I describe >>>> above. >>>> >>>> Exp: >>>> [root@build mytest]# df -ah /mytest/ >>>> Filesystem Size Used Avail Use% Mounted on >>>> /dev/sdb2 2.0G 3.1M 1.9G 1% /mytest >>>> [root@build mytest]# qemu-img create -f raw test.raw 3G >>>> Formatting 'test.raw', fmt=3Draw size=3D3221225472 >>>> [root@build mytest]# ls -l test.raw >>>> -rw-r--r--. 1 root root 3221225472 May 8 12:23 test.raw >>>> [root@build mytest]# >>>> >>>> Thank you. >>>> >>>> Best Regards >>>> Xinghai Yu >>>> >>> >> >> -- >> =E4=BB=A5=E4=B8=8A >> >> =E7=AC=AC=E4=B8=80=E8=BD=AF=E4=BB=B6=E4=BA=8B=E4=B8=9A=E9=83=A8 =E7=AC= =AC=E4=B8=80=E5=BC=80=E5=8F=91=E9=83=A8 driver=E7=BB=84 =E4=BA=8E=E6=98=9F= =E6=B5=B7 >> Best Regards >> -------------------------------------------------- >> Yu Xinghai >> Development Dept.I >> Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) >> No.6 Wenzhu Road, Nanjing, 210012, China >> TEL: +86+25-86630566-8533 >> FUJITSU INTERNAL: 7998-8533 >> FAX: +86+25-83317685 >> MAIL: yuxinghai@cn.fujitsu.com >> -------------------------------------------------- > --=20 =E4=BB=A5=E4=B8=8A =E7=AC=AC=E4=B8=80=E8=BD=AF=E4=BB=B6=E4=BA=8B=E4=B8=9A=E9=83=A8 =E7=AC=AC= =E4=B8=80=E5=BC=80=E5=8F=91=E9=83=A8 driver=E7=BB=84 =E4=BA=8E=E6=98=9F=E6= =B5=B7 Best Regards -------------------------------------------------- Yu Xinghai Development Dept.I Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No.6 Wenzhu Road, Nanjing, 210012, China TEL: +86+25-86630566-8533 FUJITSU INTERNAL: 7998-8533 FAX: +86+25-83317685 MAIL: yuxinghai@cn.fujitsu.com -------------------------------------------------- =