ZFS can't delete files when over quota

[Garrett Cooper]

On Sat, Nov 10, 2012 at 12:29 PM, Kevin Day <toasty at dragondata.com> wrote:

>
> On Nov 10, 2012, at 1:21 PM, Bryan Drewery <bryan at shatow.net> 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
> >
> > Bryan
>
>
> This also may cause unintended or weird behavior with regard to
> open/running binaries or processes that want to keep a file open.
>
> If you're trying to rm a binary that's currently in use, this is normally
> a supported feature. Old copies of the binary keep running and the disk
> space isn't actually freed until after everything holding the old version
> exits. With the patch, truncate will fail with ETXTBSY. Having rm fail with
> ETXTBSY is probably wrong.
>
> Programs are also allowed to keep reading/writing to a file that another
> process has unlinked. Unlinking a file is not supposed to destroy the
> contents of it until after everyone is done with it. Throwing a truncate in
> there changes that behavior.
>
> I realize this is only happening under already broken circumstances, but
> changing unlink to occasionally doing unlink-truncate-unlink is going to
> make some hard to debug situations occur.
>
> Also, you need to be testing errno == EDQUOT, not rval.
>

Yes. unlink(...) == -1 && errno == EDQUOT