Thread (31 messages) 31 messages, 7 authors, 2011-12-07

RE: fallocate vs ENOSPC

From: <hidden>
Date: 2011-11-28 10:42:27

-----Original Message-----
From: linux-fsdevel-owner@vger.kernel.org [mailto:linux-fsdevel-
owner@vger.kernel.org] On Behalf Of Pádraig Brady
Sent: Monday, November 28, 2011 4:55 PM
To: Dave Chinner
Cc: Theodore Tso; Christoph Hellwig; linux-fsdevel@vger.kernel.org
Subject: Re: fallocate vs ENOSPC

On 11/28/2011 05:10 AM, Dave Chinner wrote:
quoted
Quite frankly, if system utilities like cp and tar start to abuse
fallocate() by default so they can get "upfront ENOSPC detection",
then I will seriously consider making XFS use delayed allocation for
fallocate rather than unwritten extents so we don't lose the past 15
years worth of IO and aging optimisations that delayed allocation
provides us with....
For the record I was considering fallocate() for these reasons.

  1. Improved file layout for subsequent access
  2. Immediate indication of ENOSPC
  3. Efficient writing of NUL portions

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.
Just out of curiosity, how is it going to work with sparse files? By default, cp uses --sparse=auto. And for sparse files, it avoids some disk allocation automatically. With fallocate(), do you plan to change the semantics?

Cheers,
Tao
cheers,
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help