From: Christoph Hellwig Date: Fri, 13 Dec 2013 00:34:04 +0000 (+1100) Subject: xfs: format logged extents directly into the CIL X-Git-Tag: v3.14-rc1~123^2~7 X-Git-Url: https://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=da7765031de15273d370d18a5354e1d8001ce2a9;p=pandora-kernel.git xfs: format logged extents directly into the CIL With the new iop_format scheme there is no need to have a temporary buffer to format logged extents into, we can do so directly into the CIL. This also allows to remove the shortcut for big endian systems that probably hasn't gotten a lot of test coverage for a long time. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner --- diff --git a/fs/xfs/xfs_inode_fork.c b/fs/xfs/xfs_inode_fork.c index cfee14a83cfe..06abaeef1715 100644 --- a/fs/xfs/xfs_inode_fork.c +++ b/fs/xfs/xfs_inode_fork.c @@ -721,15 +721,16 @@ xfs_idestroy_fork( } /* - * xfs_iextents_copy() + * Convert in-core extents to on-disk form * - * This is called to copy the REAL extents (as opposed to the delayed - * allocation extents) from the inode into the given buffer. It - * returns the number of bytes copied into the buffer. + * For either the data or attr fork in extent format, we need to endian convert + * the in-core extent as we place them into the on-disk inode. * - * If there are no delayed allocation extents, then we can just - * memcpy() the extents into the buffer. Otherwise, we need to - * examine each extent in turn and skip those which are delayed. + * In the case of the data fork, the in-core and on-disk fork sizes can be + * different due to delayed allocation extents. We only copy on-disk extents + * here, so callers must always use the physical fork size to determine the + * size of the buffer passed to this routine. We will return the size actually + * used. */ int xfs_iextents_copy( Reading git-diff-tree failed