Re: very bad behavior on overquota writes

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Apr 14,  7:25am, Manuel Bouyer wrote:
} On Thu, Nov 22, 2012 at 12:46:54PM +0100, Manuel Bouyer wrote:
} > @@ -521,6 +527,16 @@ out:
} >             (void) UFS_TRUNCATE(vp, osize, ioflag & IO_SYNC, ap->a_cred);
} >             uio->uio_offset -= resid - uio->uio_resid;
} >             uio->uio_resid = resid;
} > +           if (error == EDQUOT || error == ENOSPC) {
} > +                   /* if the process keeps writing (e.g. nfsd),
} > +                    * UFS_TRUNCATE() may be very expensive as it
} > +                    * walks the page list. As a workaround flush and
} > +                    * free all pages associated with this vnode
} > +                    */
} > +                   (void)VOP_PUTPAGES(vp, 0, 0,
} > +                       PGO_ALLPAGES |PGO_CLEANIT | PGO_FREE | PGO_SYNCIO |
} > +                       PGO_JOURNALLOCKED);
} > +           }
} >     } else if (resid > uio->uio_resid && (ioflag & IO_SYNC) == IO_SYNC)
} >             error = UFS_UPDATE(vp, NULL, NULL, UPDATE_WAIT);
} >     else
} 
} And we should probably do this on any erorr, no only space-related errors.
} I've adjusted my local tree.

     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)?  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.

}-- End of excerpt from Manuel Bouyer