From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1I91MV-0002wI-UV
	for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:17:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1I91MU-0002vj-ND
	for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:17:51 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1I91MU-0002ve-FB
	for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:17:50 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1I91MT-0001JF-Vo
	for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:17:50 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Crash: When Host HDD is full
Date: Thu, 12 Jul 2007 17:17:31 +0100
References: <7fac565a0707110819k635d398fl273d8d5a0afd2d3f@mail.gmail.com>
	<200707120807.41162.mikeonthecomputer@gmail.com>
	<4696530A.2010000@qumranet.com>
In-Reply-To: <4696530A.2010000@qumranet.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200707121717.32145.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> > Besides, most
> > filesystems reserve some space for the superuser, now unless there's a
> > cross-platform way to figure out just how much space that is, you'd still
> > be getting errors despite having 5~10% of the filesystem technically
> > free.
>
> Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
> second or wait for user input on the monitor.

Better would IMHO be to report an IO error to the guest and allow that to 
decide what to do. If you're bothered about robustness and reliability then 
arbitrarily stopping the guest is not acceptable behaviour. There's no 
guarantee that space will become available in a finite timeframe.

Paul