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.) 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. He suggested tieing it to the file descriptor, but I wonder if it's actually more functional to tie it to the process --- that is, the process says, "guarantee that I will be able to write 5MB", and writes made by that process get counted against that 5MB reservation. When the process exits, any reservation made by that process evaporates. Whether we tie this space reservation to a fd or a process, we also would need to decide up front whether this space shows up as "missing" by statfs(2)/df or not. - 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
