Re: fallocate vs ENOSPC

["Pádraig Brady" <P@draigBrady.com>]

On 11/30/2011 03:32 PM, Ted Ts'o wrote:
> On Wed, Nov 30, 2011 at 09:28:32AM +0000, Pádraig Brady wrote:
>>
>> But then posix_fallocate() would always be slow I think,
>> requiring one to actually write the NULs.
> 
> Almost no one should ever use posix_fallocate(); it's can be a
> performance disaster because you don't know whether or not the file
> system will really do fallocate, or will do the slow "write zeros"
> thing.
> 
> You really should use fallocate(), take the failure if the file system
> doesn't support fallocate, and then you can decide what the
> appropriate thing to do might be.

s/posix_fallocate()/functionality provided by &/

I.E. copy --sparse=never could use that,
and it would be beneficial if it was as fast as possible.

I looked for a couple of minutes on the XFS preallocate behaviour,
and it seems that these ioctls pre date fallocate().
http://linux.die.net/man/3/xfsctl
I see XFS_IOC_ALLOCSP and XFS_IOC_RESVSP.
So fallocate() support was directly mapped on top of the existing ALLOCSP.
I think the specialised alignment behavior should be restricted to
direct calls to XFS_IOC_ALLOCSP to be called by xfs_mkfile(1) or whatever.
Better would be to provide generic access to that functionality
through an ALIGN option to fallocate()

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