]> git.openpandora.org Git - pandora-kernel.git/commitdiff
xfs: format logged extents directly into the CIL
authorChristoph Hellwig <hch@infradead.org>
Fri, 13 Dec 2013 00:34:04 +0000 (11:34 +1100)
committerDave Chinner <david@fromorbit.com>
Fri, 13 Dec 2013 00:34:04 +0000 (11:34 +1100)
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 <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
fs/xfs/xfs_inode_fork.c
fs/xfs/xfs_inode_item.c
fs/xfs/xfs_inode_item.h

index cfee14a83cfe601d90bdc6732cc608746aaf3e03..06abaeef17151b502c4ede690d84221407564691 100644 (file)
@@ -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(
Simple merge
Simple merge