On Tue, Feb 02, 2016 at 10:20:54AM +0100, Christoph Hellwig wrote: > On Mon, Feb 01, 2016 at 01:38:05PM -0500, J. Bruce Fields wrote: > > This is with the xfs block layout? > > > > Christoph, do we know anything about average or worst-case sizes for > > that layout update field? > > The average is rather small and fits into a single page, the worst > case is basically unlimited: > > (file size / block size) * sizeof(pnfs_block_extent) > > by the protocol, and about half that for a non-stupid client as > it would merge consecutive blocks and only trigger something close > to the worst case for a "block allocated, block hole, block allocated, ..." > pattern. OK. And what's the failure mode if the layoutcommit fails? I guess the client returns the layout and redoes IO through the MDS. For a rare failure maybe that's not so terrible. So I guess the right thing to do is take Kinglong's patch for now. After that, it wouldn't be that hard for nfsd4_block_proc_layoutcommit to decode from an array of pages. But does the iomaps array end up being just as big? --b. -- 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
