ZFS can't delete files when over quota

[Mateusz Guzik]

On Sat, Nov 10, 2012 at 08:03:01PM +0000, Chris Rees wrote:
> On 10 Nov 2012 19:48, "Mateusz Guzik" <mjguzik at gmail.com> wrote:
> >
> > On Sat, Nov 10, 2012 at 01:21:38PM -0600, Bryan Drewery wrote:
> > > On 11/10/2012 12:55 PM, Chris Rees wrote:
> > > > Bryan,
> > > >
> > > > Please try the patch at [1]; if it works I'll document it.
> > > >
> > > > Chris
> > > >
> > > > [1] http://www.bayofrum.net/~crees/patches/bdrewery.diff
> > > >
> > >
> > > Hmm, I'm not a fan of -T. I think it should just work out-of-the-box
> here.
> > >
> > > Something like:
> > >
> > > http://people.freebsd.org/~bdrewery/rm-quota.txt
> > >
> >
> > I think this approach is incorrect.
> >
> > If you cannot rm $file due to EDQUOT, but truncate $file && rm $file
> > works (and both patches try to do this), then I think this is a
> filesystem bug.
> 
> Quite right, but this has been a known issue in ZFS for a while, without a
> forthcoming fix.
> 
> I'll do some grovelling in the zfs code tomorrow, wish me luck-- I don't
> expect to be productive.
> 

In this case the right fix (whatever it is) may be really non-trivial.

I'm in mood for ugly hacks, so:
You can think of a workardound in the kernel. If removal fails with
EDQUOT and you can guarantee that no thread has this file opened and
truncation will allow removal to succeed, you truncate and remove.
Determining whether truncation will be able to help (and making sure that
these conditions hold until removal is finised) may be non-trivial as well.

But I doubt something like this could be accepted. :)

My point is that even if this problem persists, changing tools in the
basesystem to cope is a bad idea. If you are happy with only rm being able
to cope, you can wrap/alias it on your machines.

-- 
Mateusz Guzik <mjguzik gmail.com>