Re: [Qemu-devel] Crash: When Host HDD is full

[Avi Kivity <avi@qumranet.com>]

Paul Brook wrote:
>>>> 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
>>     
>
> If an guest OS ignores IO write errors it's just plain broken.
>
>   

Linux 2.4 ignores IO write errors under certain conditions.  Yes, it's 
broken.  But you're making the user suffer for this brokenness even if 
the only thing wrong is a temporary shortage of disk space.

>> - 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.
>>     
>
> I don't buy this argument.  If you don't want "unexpected" things to happen 
> then the solution is simple: Make sure you never run out of disk space. 
>   

That's unrealistic, at least for the casual user running qemu.  A 
managed solution can probably work around this.

Qemu should be more user friendly.

> The fact is that your (virtual) disk *is* broken at this point. The guest OS 
> is in a much better position to decide on an appropriate course of action, 
> either by retrying or some other recovery mechanism.
>
>   

I don't see why it is broken.  The disk contents have not changed since 
after the last successful write.  Once you free some space you can 
continue writing.

Note that a recovery mechanism that involves writing will likely fail as 
well, possibly corrupting the disk in the process.

> There are various error contitions that could be used, for example 
> write-protect.
>   

The guest would most likely be surprised at getting a write-protect 
error on its hard disk, and then the disk *would* be broken.

-- 
error compiling committee.c: too many arguments to function