Re: [RFC] [PATCHv3 7/9] reiser4: batch discard support: actually implement the FITRIM ioctl handler.

[Edward Shishkin <edward.shishkin@gmail.com>]

On 10/21/2014 06:23 PM, Ivan Shapovalov wrote:
> On Tuesday 21 October 2014 at 18:21:56, Edward Shishkin wrote:	
>> On 10/21/2014 06:18 PM, Ivan Shapovalov wrote:
>>> On Tuesday 21 October 2014 at 12:14:02, Edward Shishkin wrote:	
>>>> On 10/21/2014 12:39 AM, Ivan Shapovalov wrote:
>>>>> On Monday 20 October 2014 at 12:54:13, Edward Shishkin wrote:	
>>>>>> On 08/17/2014 11:52 PM, Ivan Shapovalov wrote:
>>>>>>> [...]
>>>>>>> +		/*
>>>>>>> +		 * Grab some sane amount of space.
>>>>>>> +		 * We will allocate blocks until end of the partition or until
>>>>>>> +		 * the grabbed space is exhausted.
>>>>>>> +		 */
>>>>>>> +		ret = reiser4_grab_reserved(super, 0, BA_CAN_COMMIT | BA_SOME_SPACE);
>>>>>>    any "legitimate" user of the reserved space
>>>>>> will block on the mutex and eventually proceed. At the same time, given
>>>>>> a filesystem with (5% + eps) free space left, not using the reserved space
>>>>>> will result in trimming of (eps) blocks at a time.
>>>>>>
>>>>>> reiser4_grab_reserved() grabs space from the reserved area (5%).
>>>>>> This is needed to make sure that unlink(), truncate(), etc. won't
>>>>>> fail, if there is no free space on disk. I don't think that FITRIM
>>>>>> ioctl needs this reserved area.
>>>>> Well, IIUC, it doesn't hurt:
>>>> "doesn't hurt" is not enough. If you want to take a resource,
>>>> you should be going to explain, why do you need this.
>>> I've explained the reason below... isn't it sufficient?
>>
>> Sorry, but I don't see any explanation.
> "given a filesystem with (5% + eps) free space left, not using the reserved
> space will result in trimming of (eps) blocks at a time."
>


This is something that I am not able to parse :)

Ok, it is clear, why we can not fail with -ENOSPC when trying to delete
a file from a full partition, yes?
I want to see explanation, why FITRIM ioclt can not finish the work when
there is no free space on disk.

Thanks,
Edward.