]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commitdiff
Btrfs: fix typos in comments
authorWu Fengguang <fengguang.wu@intel.com>
Thu, 2 Apr 2009 20:46:06 +0000 (16:46 -0400)
committerChris Mason <chris.mason@oracle.com>
Thu, 2 Apr 2009 20:46:06 +0000 (16:46 -0400)
Signed-off-by: Chris Mason <chris.mason@oracle.com>
fs/btrfs/ctree.h
fs/btrfs/locking.c
fs/btrfs/volumes.h

index bb6ac5b8765223df56ccea44375d8ba615897a7f..8f4e152bb11b71c0c8cf594efb37b1454ddc0084 100644 (file)
@@ -143,12 +143,15 @@ static int btrfs_csum_sizes[] = { 4, 0 };
 #define BTRFS_FT_MAX           9
 
 /*
- * the key defines the order in the tree, and so it also defines (optimal)
- * block layout.  objectid corresonds to the inode number.  The flags
- * tells us things about the object, and is a kind of stream selector.
- * so for a given inode, keys with flags of 1 might refer to the inode
- * data, flags of 2 may point to file data in the btree and flags == 3
- * may point to extents.
+ * The key defines the order in the tree, and so it also defines (optimal)
+ * block layout.
+ *
+ * objectid corresponds to the inode number.
+ *
+ * type tells us things about the object, and is a kind of stream selector.
+ * so for a given inode, keys with type of 1 might refer to the inode data,
+ * type of 2 may point to file data in the btree and type == 3 may point to
+ * extents.
  *
  * offset is the starting byte offset for this key in the stream.
  *
@@ -200,7 +203,7 @@ struct btrfs_dev_item {
 
        /*
         * starting byte of this partition on the device,
-        * to allowr for stripe alignment in the future
+        * to allow for stripe alignment in the future
         */
        __le64 start_offset;
 
@@ -958,7 +961,6 @@ struct btrfs_root {
 };
 
 /*
-
  * inode items have the data typically returned from stat and store other
  * info about object characteristics.  There is one for every file and dir in
  * the FS
@@ -989,7 +991,7 @@ struct btrfs_root {
 #define BTRFS_EXTENT_CSUM_KEY  128
 
 /*
- * root items point to tree roots.  There are typically in the root
+ * root items point to tree roots.  They are typically in the root
  * tree used by the super block to find all the other trees
  */
 #define BTRFS_ROOT_ITEM_KEY    132
index a5310c0f41e24f089bfd78e3a2f0939d3957f717..1c36e5cd8f55495843631f7e5d3e6245d47684dd 100644 (file)
@@ -60,8 +60,8 @@ void btrfs_clear_lock_blocking(struct extent_buffer *eb)
 
 /*
  * unfortunately, many of the places that currently set a lock to blocking
- * don't end up blocking for every long, and often they don't block
- * at all.  For a dbench 50 run, if we don't spin one the blocking bit
+ * don't end up blocking for very long, and often they don't block
+ * at all.  For a dbench 50 run, if we don't spin on the blocking bit
  * at all, the context switch rate can jump up to 400,000/sec or more.
  *
  * So, we're still stuck with this crummy spin on the blocking bit,
index 86c44e9ae1101e2332dadad41b6def15932ae96c..2185de72ff7dad59154f5a568624be89ab7e8b97 100644 (file)
@@ -76,7 +76,7 @@ struct btrfs_device {
 struct btrfs_fs_devices {
        u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
 
-       /* the device with this id has the most recent coyp of the super */
+       /* the device with this id has the most recent copy of the super */
        u64 latest_devid;
        u64 latest_trans;
        u64 num_devices;