summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorSteven Whitehouse <swhiteho@redhat.com>2014-02-04 15:45:11 +0000
committerSteven Whitehouse <swhiteho@redhat.com>2014-02-04 15:45:11 +0000
commitb2c8b3ea871e478ac144f617d015d3aa55fc3aa8 (patch)
tree85d094c3125b147bfddbb6e509fd9c238e1125f6 /include
parent885bceca7ff12021c9c17f58d12e12ec6e8e59a6 (diff)
downloadlinux-stable-b2c8b3ea871e478ac144f617d015d3aa55fc3aa8.tar.gz
linux-stable-b2c8b3ea871e478ac144f617d015d3aa55fc3aa8.tar.bz2
linux-stable-b2c8b3ea871e478ac144f617d015d3aa55fc3aa8.zip
GFS2: Allocate block for xattr at inode alloc time, if required
This is another step towards improving the allocation of xattr blocks at inode allocation time. Here we take advantage of Christoph's recent work on ACLs to allocate a block for the xattrs early if we know that we will be adding ACLs to the inode later on. The advantage of that is that it is much more likely that we'll get a contiguous run of two blocks where the first is the inode and the second is the xattr block. We still have to fall back to the original system in case we don't get the requested two contiguous blocks, or in case the ACLs are too large to fit into the block. Future patches will move more of the ACL setting code further up the gfs2_inode_create() function. Also, I'd like to be able to do the same thing with the xattrs from LSMs in due course, too. That way we should be able to slowly reduce the number of independent transactions, at least in the most common cases. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'include')
-rw-r--r--include/uapi/linux/gfs2_ondisk.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/include/uapi/linux/gfs2_ondisk.h b/include/uapi/linux/gfs2_ondisk.h
index 0f24c07aed51..310020816809 100644
--- a/include/uapi/linux/gfs2_ondisk.h
+++ b/include/uapi/linux/gfs2_ondisk.h
@@ -347,9 +347,9 @@ struct gfs2_leaf {
* metadata header. Each inode, if it has extended attributes, will
* have either a single block containing the extended attribute headers
* or a single indirect block pointing to blocks containing the
- * extended attribure headers.
+ * extended attribute headers.
*
- * The maximim size of the data part of an extended attribute is 64k
+ * The maximum size of the data part of an extended attribute is 64k
* so the number of blocks required depends upon block size. Since the
* block size also determines the number of pointers in an indirect
* block, its a fairly complicated calculation to work out the maximum