Re: very bad behavior on overquota writes

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 22, 2012 at 08:07:14PM +0100, Manuel Bouyer wrote:
 > On Thu, Nov 22, 2012 at 11:00:34AM -0800, John Nemeth wrote:
 > >      Would that prevent recovering in the case where the user
 > > disconnects a device (typical example is a thumb drive) and later
 > > reconnects it (once we have the ability to handle this situation)?
 > 
 > It probably depends on how it will be done, but I don't think so.
 > 
 > > I
 > > guess that depends whether requests are held at the file system layer
 > > or the device layer?  At this point, dropping the blocks should
 > > probably only be done when the error is known to be permanent.
 > 
 > the blocks are not dropped. They are flushed to backing store before
 > being deallocated. If we have the ability to disconnect/reconnect
 > removable devices, I would expect requests to the device to
 > hang waiting for the device to be available again, rather than returning
 > an error.

Not necessarily; if nothing else one might want two modes (like soft
and hard NFS mounts)... but besides that, in the case where the device
is ejected and then becomes unavailable, such as if you pop out a USB
stick and hand it to someone who's going home for the weekend, then
realize you forgot to unmount... there has to be a way to bail out,
and the last thing you want at that point is for the system to start
issuing a whole new set of I/O requests to the device.

I also worry about cases where an EIO due to a bad block triggers this
flush; for a device where the hard I/O error cycle is slow this could
wedge the system for minutes.

I'd say the logic should be limited to the ENOSPC and EDQUOT cases.

(Also it would be nice if we could wedge in some logic to warn the
user about software that triggers this case.)

-- 
David A. Holland
dholland%netbsd.org@localhost