From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: fallocate vs ENOSPC Date: Fri, 25 Nov 2011 05:40:50 -0500 Message-ID: <20111125104050.GA26729@infradead.org> References: <4ECF6D41.2040801@draigBrady.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: P??draig Brady Return-path: Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:37098 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753764Ab1KYKkv (ORCPT ); Fri, 25 Nov 2011 05:40:51 -0500 Content-Disposition: inline In-Reply-To: <4ECF6D41.2040801@draigBrady.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Nov 25, 2011 at 10:26:09AM +0000, P??draig Brady wrote: > I was wondering about adding fallocate() to cp, > where one of the benefits would be immediate indication of ENOSPC. > I'm now wondering though might fallocate() fail to allocate an > extent with ENOSPC, but there could be fragmented space available to write()? fallocate isn't guaranteed to allocate a single or even contiguous extents, it just allocate the given amount of space, and if the fs isn't too fragmented and the allocator not braindead it will be sufficiently contiguous. Also all Linux implementation may actually still fail a write later if extreme corner cases when btree splits or other metadata operations during unwritten extent conversions go over the space limit.