From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I91gV-00026J-Rh for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:38:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I91gR-00024t-Ku for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:38:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I91gR-00024o-FX for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:38:27 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I91gP-0007ji-Iq for qemu-devel@nongnu.org; Thu, 12 Jul 2007 12:38:26 -0400 Message-ID: <46965902.6030305@qumranet.com> Date: Thu, 12 Jul 2007 19:38:26 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Crash: When Host HDD is full References: <7fac565a0707110819k635d398fl273d8d5a0afd2d3f@mail.gmail.com> <200707120807.41162.mikeonthecomputer@gmail.com> <4696530A.2010000@qumranet.com> <200707121717.32145.paul@codesourcery.com> In-Reply-To: <200707121717.32145.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: >>> 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. > I've considered that, and I'm not sure. You will likely get a storm of I/O errors on ENOSPC; with several ways for disaster to strike: - the guest doesn't handle I/O errors well, and keeps writing. some of the writes are overwrites so they hit the disk and data is corrupted - the guest decides the disk is bad because it has too many errors and initiates some recovery procedure Stopping the guest at least guarantees nothing unexpected happens. If it's part of a managed solution we can output a message to the monitor which eventually finds its way to the operator. -- error compiling committee.c: too many arguments to function