ZFS can't delete files when over quota

[Chris Rees]

On 10 November 2012 20:29, 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.

These are the reasons I added the -T option, which I realise would
have been more correct as -t; it's undesirable to have as default
behaviour.  In my patch, errno is tested.

Chris