Re: fallocate vs ENOSPC

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

On 11/30/2011 05:01 PM, Ted Ts'o wrote:
> On Wed, Nov 30, 2011 at 04:11:27PM +0000, Pádraig Brady wrote:
>> 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()
> 
> Well, XFS_IOC_RESVSP is the same as fallocate with the
> FALLOC_FL_KEEP_SIZE flag.  That is to say, blocks are allocated and
> attached to the inode --- that is, which blocks out of the pool of
> free blocks should be selected is decided at the time that you call
> fallocate() with the KEEP_SIZE flag or use the XFS_IOC_RESVSP ioctl
> (which by the way works on any file system that supports fallocate on
> modern kernels --- the kernel provides the translation from
> XFS_IOC_RESVSP to fallocate/KEEP_SIZE in fs/ioctl.c's
> ioctl_preallocate() function.)

Thanks for the clarification.
My main point is that these related ioctls existed before fallocate.

> What Dave was talking about is something different.  He's suggesting a
> new call which reserves space, but which does not actually make the
> block allocation decision until the time of the write.

Yes that was clear.
I'm still not sure it's needed TBH.
The separation of functionality is needed for the reasons Dave detailed,
but it might be better to add an ALIGN flag to fallocate for
that special use case.
I'm not trying to enforce my argument with repetition here,
just trying to be clear.

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