On Fri, Nov 25, 2011 at 05:40:50AM -0500, Christoph Hellwig wrote:
> 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.
While this is true, *usually* fallocate will allocate enough space,
but as Cirstoph has said, you still have to check the error returns
for the write(2) and close(2) system call, and deal appropriately with
any errors.
The other reason to use fallocate is if you are copying a huge number
of files, it's possible you'll get better block allocation layout,
depending on the file system, and how insane the writeback code for a
particular kernel version might be. (Some versions of the kernel had
writeback algorithms that would write 4MB of one file, then 4MB for
another file, then 4MB for yet another file, then 4MB of the first
file, etc. --- and some file systems can deal with this kind of write
pattern better than others.) Using fallocate if you know the size of
the file up front won't hurt, and on some systems it might help.
- Ted
--
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
