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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
