On Oct 29, 2013, at 8:48 AM, Hellwig Christoph <hch@xxxxxxxxxxxxx> wrote: > On Tue, Oct 29, 2013 at 12:44:50PM +0000, Myklebust, Trond wrote: >> It exists because the server vendors were worried that operations such as preallocation and/or hole punching can take a more or less unbounded amount of time due to the 64-bit size. By using an (optional) callback method, the server can free up the RPC slot that would otherwise be kept waiting in the synchronous case. > > Must be some horried filesystems on those vendors servers. Both > operations should be O(nr_extents), where nr_extents should be extremely > low for the preallocation and still reasonably low for hole punches, > although users control the allocastion pattern. > > There's a reason why these aren't aio operations locally either. > Imagine someone wanting to punch a 50TB hole in NTFS, for instance. It doesn't have real holes, so you'd end up needing to zero out the existing extents in that region of the file. That will take time, even with an O(nr_extents) algorithm. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
