bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Azat Khuzhin
Subject: bug#17470: [PATCH] sort: rotate on ENOSPC while creating tmp files
Date: Wed, 14 May 2014 15:07:02 +0400
User-agent: Mutt/1.5.23 (2014-03-12)

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.
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?

Thanks,
Azat.

> 
> In this case there are various schemes for coalescing multiple storage 
> locations
> to a single mount point (mhddfs, lvm, raid, ...), and since these have a more
> system wide view, it would be better to avoid implementing similar but limited
> logic within sort.
> 
> thanks,
> Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]