Re: Removing file = quota exceded

[Kevin Brandstatter <icarusthecow@gmail.com>]

On 06/22/2014 11:38 AM, Josef Bacik wrote:
> On 06/21/2014 06:16 PM, Kevin Brandstatter wrote:
>> so ive come accross the issue of being unable to remove a file when a
>> subvolume quota is reached. This can be resolved by truncating the file
>> first, or removing the quota temporarily.
>> However, it should be reasonable that you should alwasy be able to
>> remove a file, regardless of quota limitations yes?
>> Upon delving into the code, I found the comment that an unlink may not
>> always free space. This seems reasonable on a COW filesystem, however,
>> it should not preclude a removal IMO (please correct me if i missed
>> something)
>> Personally I'm looking to try and fix this issue to allow a removal of a
>> file even when the subvol quota has been reached. I'm hoping one of the
>> current developers may be able to assist me in where to focus my
>> efforts, as I am still unable to follow exactly where a remove operation
>> would check the quota limitations.
>> Any help is appreciated.
>>
>
> For quota I think we should always allow unlink, it's not really the
> users fault
> that we sometimes won't actually remove space with unlink.  The normal
> ENOSPC
> stuff still needs to take this into account of course but for quota I
> think it's
> ok to just go over quota.  I'll look into this later this week.  Thanks,
>
> Josef
I was able to trace the error to the __unlink_start_trans, and noticed
the handling for the
ENOSPC error code. I modified this function to do the same in the case
of the EDQUOT error
(the one that gets returned when the quota is exceded). When I did this
i was able to remove a file even when the quota was reached. Submitted
the patch to the mailing list for feedback.

-Kevin