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.