Re: fallocate vs ENOSPC

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

 



On 11/28/2011 02:36 PM, Theodore Tso wrote:
> 
> On Nov 28, 2011, at 3:55 AM, Pádraig Brady wrote:
> 
>>
>> You lucidly detailed issues with 1. which I suppose could be somewhat
>> mitigated by not fallocating < say 1MB, though I suppose file systems
>> could be smarter here and not preallocate small chunks (or when
>> otherwise not appropriate). We can already get ENOSPC from a write()
>> after an fallocate() in certain edge cases, so it would probably make
>> sense to expand those cases.
> 
> I'm curious -- why are you so worried about ENOSPC?
> 
> You need to check the error returns on write(2) anyway (and it's good
> programming practice anyways --- don't forget to check on close because
> some network file systems only push to the network on close, and in
> some cases they might only get quota errors on the close), so I don't see
> why using fallocate() to get an early ENOSPC is so interesting for you.

It would be better to indicate ENOSPC _before_ copying a (potentially large)
file to a (potentially slow) device. If the implementation complexity
and side effects of doing this are sufficiently small, then it's worth
doing. These discussions are to quantify the side effects.

cheers,
Pádraig.

p.s. You can be sure that `cp` deals with errors from write() and close().
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux