bug#17470: [PATCH] sort: rotate on ENOSPC while creating tmp files

[Pádraig Brady]

On 05/14/2014 12:07 PM, Azat Khuzhin wrote:
> On Mon, May 12, 2014 at 12:22:45AM +0100, Pádraig Brady wrote:
>> tag 17470 wontfix
>> close 17470
>> stop
>>
>> On 05/11/2014 11:25 PM, Paul Eggert wrote:
>>> Azat Khuzhin wrote:
>>>
>>>> +      fd = mkstemp (file);
>>>> +
>>>> +      if (errno != ENOSPC || temp_dir_index == start_dir_index)
>>>
>>> This assumes that when mkstemp succeeds then errno != ENOSPC, which is not 
>>> necessarily true.
>>>
>>> More generally, it appears that with the patch 'sort' checks whether one 
>>> can create a file, but 'sort' will still respond poorly if a write to a 
>>> temp file fails due to filesystem space exhaustion.
>>
>> Yes I agree.
>>
>> Now one could use fallocate() where available to preallocate a given amount 
>> of space,
>> however allocation management can be done outside of sort(1). As a rule of 
>> thumb,
>> if it's possible to implement outside of a particular functional unit, then 
>> it
>> probably should be done outside.
> 
> Sometimes it's not possible to do this, because it will likely need in
> erasing data in all involved partitions, or it can make _all_ data
> unavailable when one of disks will fail.

There are many external solutions to that problem.

> And it more simpler to use just sort(1) instead of
> fdisk/pvcreate/mdadm/...(1).
> Occasionally, even restart can be painfull.
> 
> And this patch is relatively small, so this is not even an _allocation
> managemenet_.
> Maybe if I will update patch to do this only under specific option, what
> you think?

Well it shouldn't need any interface changes as sort already accepts multiple 
-T options.
However it wouldn't be that simple either requiring fallocations, which are not
generally available and which don't guarantee that writes will not give ENOSPC.
Also do we always know how much to fallocate? Would that have efficiency 
problems
compared to dynamic allocate? What about sort --compress, ...

So still not convinced sorry.

Pádraig.