fix quoted text markings

Use asciidoc quotes for quoted strings.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

7 files changed, 97 insertions, 97 deletions

diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
index 7d4c11b..0527ecc 100644
--- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
+++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
@@ -93,7 +93,7 @@ struct xfs_sb
 };
 ----
 *sb_magicnum*::
-Identifies the filesystem. Its value is +XFS_SB_MAGIC = 0x58465342 "XFSB"+.
+Identifies the filesystem. Its value is +XFS_SB_MAGIC+ ``XFSB'' (0x58465342).
 
 *sb_blocksize*::
 The size of a basic unit of space allocation in bytes. Typically, this is 4096
@@ -269,7 +269,7 @@ Miscellaneous flags.
 |=====
 
 *sb_shared_vn*::
-Reserved and must be zero ("vn" stands for version number).
+Reserved and must be zero (``vn'' stands for version number).
 
 *sb_inoalignmt*::
 Inode chunk alignment in fsblocks.
@@ -413,8 +413,8 @@ All block numbers, indexes, and counts are AG relative.
 === AG Free Space Block
 
 The second sector in an AG contains the information about the two free space
-B+trees and associated free space information for the AG. The "AG Free Space
-Block", also knows as the +AGF+, uses the following structure:
+B+trees and associated free space information for the AG. The ``AG Free Space
+Block'' also knows as the +AGF+, uses the following structure:
 
 [source, c]
 ----
@@ -441,7 +441,7 @@ index 0 for the free space B+tree indexed by block number; and index 1 for the
 free space B+tree indexed by extent size.
 
 *agf_magicnum*::
-Specifies the magic number for the AGF sector: "XAGF" (0x58414746).
+Specifies the magic number for the AGF sector: ``XAGF'' (0x58414746).
 
 *agf_versionnum*::
 Set to +XFS_AGF_VERSION+ which is currently 1.
@@ -460,17 +460,17 @@ Specifies the block number for the root of the two free space B+trees.
 
 *agf_levels*::
 Specifies the level or depth of the two free space B+trees. For a fresh AG, this
-will be one, and the "roots" will point to a single leaf of level 0.
+will be one, and the ``roots'' will point to a single leaf of level 0.
 
 *agf_flfirst*::
-Specifies the index of the first "free list" block. Free lists are covered in
+Specifies the index of the first ``free list'' block. Free lists are covered in
 more detail later on.
 
 *agf_fllast*::
-Specifies the index of the last "free list" block.
+Specifies the index of the last ``free list'' block.
 
 *agf_flcount*::
-Specifies the number of blocks in the "free list".
+Specifies the number of blocks in the ``free list''.
 
 *agf_freeblks*::
 Specifies the current number of free blocks in the AG.
@@ -551,8 +551,8 @@ typedef __be32 xfs_alloc_ptr_t;
 
 * As the free space tracking is AG relative, all the block numbers are only
 32-bits.
-* The +bb_magic+ value depends on the B+tree: "ABTB" (0x41425442) for the block
-offset B+tree, "ABTC" (0x41425443) for the block count B+tree.
+* The +bb_magic+ value depends on the B+tree: ``ABTB'' (0x41425442) for the block
+offset B+tree, ``ABTC'' (0x41425443) for the block count B+tree.
 * The +xfs_btree_sblock_t+ header is used for intermediate B+tree node as well
 as the leaves.
 * For a typical 4KB filesystem block size, the offset for the +xfs_alloc_ptr_t+
@@ -741,7 +741,7 @@ struct xfs_agi {
 }
 ----
 *agi_magicnum*::
-Specifies the magic number for the AGI sector: "XAGI" (0x58414749).
+Specifies the magic number for the AGI sector: ``XAGI'' (0x58414749).
 
 *agi_versionnum*::
 Set to +XFS_AGI_VERSION+ which is currently 1.
diff --git a/design/XFS_Filesystem_Structure/data_extents.asciidoc b/design/XFS_Filesystem_Structure/data_extents.asciidoc
index 5df6623..af9ba44 100644
--- a/design/XFS_Filesystem_Structure/data_extents.asciidoc
+++ b/design/XFS_Filesystem_Structure/data_extents.asciidoc
@@ -3,7 +3,7 @@
 
 XFS manages space using extents, which are defined as a starting location and
 length.  A fork in an XFS inode maps a logical offset to a space extent.  This
-enables a file's extent map to support sparse files (i.e. "holes" in the file).
+enables a file's extent map to support sparse files (i.e. ``holes'' in the file).
 A flag is also used to specify if the extent has been preallocated but has not
 yet been written (unwritten extent).
 
@@ -259,7 +259,7 @@ struct xfs_btree_lblock {
 ----
 
 *bb_magic*::
-Specifies the magic number for the BMBT block: "BMAP" (0x424d4150).
+Specifies the magic number for the BMBT block: ``BMAP'' (0x424d4150).
 
 *bb_level*::
 The level of the tree in which this block is found.  If this value is 0, this
diff --git a/design/XFS_Filesystem_Structure/directories.asciidoc b/design/XFS_Filesystem_Structure/directories.asciidoc
index 73ede11..b539535 100644
--- a/design/XFS_Filesystem_Structure/directories.asciidoc
+++ b/design/XFS_Filesystem_Structure/directories.asciidoc
@@ -5,16 +5,16 @@
 Only v2 directories covered here. v1 directories are obsolete.
 
 [NOTE]
-The term "block" in this section will refer to directory blocks, not filesystem
+The term ``block'' in this section will refer to directory blocks, not filesystem
 blocks unless otherwise specified.
 
-The size of a "directory block" is defined by the xref:Superblocks[superblock's]
+The size of a ``directory block'' is defined by the xref:Superblocks[superblock's]
 +sb_dirblklog+ value. The size in bytes = +sb_blocksize+ × 2^sb_dirblklog^.
 For example, if +sb_blocksize+ = 4096 and +sb_dirblklog+ = 2, the directory block
 size is 16384 bytes. Directory blocks are always allocated in multiples based on
 +sb_dirblklog+. Directory blocks cannot be more that 65536 bytes in size.
 
-All directory entries contain the following "data":
+All directory entries contain the following ``data'':
 
 * The entry's name (counted string consisting of a single byte +namelen+
 followed by +name+ consisting of an array of 8-bit chars without a NULL
@@ -26,17 +26,17 @@ directories.
 
 * An +offset+ or +tag+ used for iterative readdir calls.
 
-All non-shortform directories also contain two additional structures: "leaves"
-and "freespace indexes".
+All non-shortform directories also contain two additional structures: ``leaves''
+and ``freespace indexes''.
 
 * Leaves contain the sorted hashed name value (+xfs_da_hashname()+ in
-xfs_da_btree.c) and associated "address" which points to the effective offset
+xfs_da_btree.c) and associated ``address'' which points to the effective offset
 into the directory's data structures. Leaves are used to optimise lookup
 operations.
 
 * Freespace indexes contain free space/empty entry tracking for quickly finding an
 appropriately sized location for new entries. They maintain the largest free
-space for each "data" block.
+space for each ``data'' block.
 
 A few common types are used for the directory structures:
 
@@ -52,11 +52,11 @@ typedef __uint32_t xfs_dir2_dataptr_t;
 
 * Directory entries are stored within the inode.
 
-* The only data stored is the name, inode number, and offset.  No "leaf" or
-"freespace index" information is required as an inode can only store a few
+* The only data stored is the name, inode number, and offset.  No ``leaf'' or
+``freespace index'' information is required as an inode can only store a few
 entries.
 
-* "." is not stored (as it's in the inode itself), and ".." is a dedicated
+* ``.'' is not stored (as it's in the inode itself), and ``..'' is a dedicated
 +parent+ field in the header.
 
 * The number of directories that can be stored in an inode depends on the
@@ -216,7 +216,7 @@ cO: 00 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 ----
 
 Next, an entry is deleted (frame000001.tst), and any entries after the deleted
-entry are moved or compacted to "cover" the hole:
+entry are moved or compacted to ``cover'' the hole:
 
 ----
 xfs_db> inode <inode#>
@@ -330,13 +330,13 @@ u3.sfdir3.list[6].filetype = 2
 
 When the shortform directory space exceeds the space in an inode, the directory
 data is moved into a new single directory block outside the inode. The inode's
-format is changed from "local" to "extent". Following is a list of points about
+format is changed from ``local'' to ``extent'' Following is a list of points about
 block directories.
 
-* All directory data is stored within the one directory block, including "." and
-".." entries which are mandatory.
+* All directory data is stored within the one directory block, including ``.'' and
+``..'' entries which are mandatory.
 
-* The block also contains "leaf" and "freespace index" information.
+* The block also contains ``leaf'' and ``freespace index'' information.
 
 * The location of the block is defined by the inode's in-core
 xref:Extent_List[extent list]: the +di_u.u_bmx[0]+ value. The file offset in
@@ -494,7 +494,7 @@ Following is a diagram of how these pieces fit together for a block directory.
 .Block directory layout
 image::images/43.png[]
 
-* The magic number in the header is "XD2B" (0x58443242).
+* The magic number in the header is ``XD2B'' (0x58443242).
 
 * The +tag+ in the +xfs_dir2_data_entry_t+ structure stores its offset from the
 start of the block.
@@ -556,7 +556,7 @@ core.nextents = 1
 u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,2097164,1,0]
 ----
 
-Go to the "startblock" and show the raw disk data:
+Go to the ``startblock'' and show the raw disk data:
 
 ----
 xfs_db> dblock 0
@@ -584,7 +584,7 @@ xfs_db> p
 130: ff ff 0e 78 00 00 00 00 00 00 00 00 00 00 00 00 ...x............
 ----
 
-The "leaf" and "tail" structures are stored at the end of the block, so as the
+The ``leaf'' and ``tail'' structures are stored at the end of the block, so as the
 directory grows, the middle is filled in:
 
 ----
@@ -652,7 +652,7 @@ btail.stale = 0
 ----
 
 [NOTE]
-For block directories, all xfs_db fields are preceded with "b".
+For block directories, all xfs_db fields are preceded with ``b''.
 
 For a simple lookup example, the hash of frame000000.tst is 0xb3a040b4. Looking
 up that value, we get an address of 0x6. Multiply that by 8, it becomes offset
@@ -692,7 +692,7 @@ btail.count = 10
 btail.stale = 1
 ----
 
-A new "bestfree" value is added for the entry, the start of the entry is marked
+A new ``bestfree'' value is added for the entry, the start of the entry is marked
 as unused with 0xffff (which overwrites the inode number for an actual entry),
 and the length of the space. The tag remains intact at the +offset+length -
 sizeof(tag)+. The address for the hash is also cleared. The affected areas are
@@ -721,24 +721,24 @@ ff0: f3 a0 40 b4 00 00 00 1a 00 00 00 0a *00 00 00 01* .................
 
 Once a Block Directory has filled the block, the directory data is changed into
 a new format. It still uses xref:Data_Extents[extents] and the same basic
-structures, but the "data" and "leaf" are split up into their own extents. The
-"leaf" information only occupies one extent. As "leaf" information is more
-compact than "data" information, more than one "data" extent is common.
+structures, but the ``data'' and ``leaf'' are split up into their own extents. The
+``leaf'' information only occupies one extent. As ``leaf'' information is more
+compact than ``data'' information, more than one ``data'' extent is common.
 
 * Block to Leaf conversions retain the existing block for the data entries and
 allocate a new block for the leaf and freespace index information.
 
 * As with all directories, data blocks must start at logical offset zero.
 
-* The "leaf" block has a special offset defined by +XFS_DIR2_LEAF_OFFSET+.
+* The ``leaf'' block has a special offset defined by +XFS_DIR2_LEAF_OFFSET+.
 Currently, this is 32GB and in the extent view, a block offset of
 32GB / +sb_blocksize+. On a 4KB block filesystem, this is 0x800000 (8388608
 decimal).
 
-* Blocks with directory entries ("data" extents) have the magic number "X2D2"
+* Blocks with directory entries (``data'' extents) have the magic number ``X2D2''
 (0x58443244).
 
-* The "data" extents have a new header (no "leaf" data):
+* The ``data'' extents have a new header (no ``leaf'' data):
 
 [source, c]
 ----
@@ -756,7 +756,7 @@ Union of directory and unused entries, exactly the same as in a block directory.
 
 // split lists
 
-* The "leaf" extent uses the following structures:
+* The ``leaf'' extent uses the following structures:
 
 [source, c]
 ----
@@ -844,7 +844,7 @@ Padding to maintain alignment.
 * The size of the +ents+ array is specified by +hdr.count+.
 
 * The size of the +bests+ array is specified by the +tail.bestcount+, which is
-also the number of "data" blocks for  the directory. The bests array maintains
+also the number of ``data'' blocks for  the directory. The bests array maintains
 each data block's +bestfree[0].length+ value.
 
 .Leaf directory free entry detail
@@ -876,8 +876,8 @@ u.bmx[0-2] = [startoff,startblock,blockcount,extentflag]
           2:[8388608,4718605,1,0]
 ----
 
-As can be seen in this example, three blocks are used for "data" in two extents,
-and the "leaf" extent has a logical offset of 8388608 blocks (32GB).
+As can be seen in this example, three blocks are used for ``data'' in two extents,
+and the ``leaf'' extent has a logical offset of 8388608 blocks (32GB).
 
 Examining the first block:
 
@@ -931,9 +931,9 @@ du[119].tag = 0xff0
 ----
 
 [NOTE]
-The xfs_db field output is preceded by a "d" for "data".
+The xfs_db field output is preceded by a ``d'' for ``data''.
 
-The next "data" block:
+The next ``data'' block:
 
 ----
 xfs_db> dblock 1
@@ -1015,7 +1015,7 @@ du[3].length = 0xf90
 du[3].tag = 0x70
 ----
 
-Examining the "leaf" block (with the fields preceded by an "l" for "leaf"):
+Examining the ``leaf'' block (with the fields preceded by an ``l'' for ``leaf''):
 
 ----
 xfs_db> dblock 8388608
@@ -1040,7 +1040,7 @@ ltail.bestcount = 3
 ----
 
 Note how the +lbests+ array correspond with the +bestfree[0].length+ values in
-the "data" blocks:
+the ``data'' blocks:
 
 ----
 xfs_db> dblock 0
@@ -1098,28 +1098,28 @@ spaces.
 [[Node_Directories]]
 == Node Directories
 
-When the "leaf" information fills a block, the extents undergo another
-separation. All "freeindex" information moves into its own extent. Like Leaf
-Directories, the "leaf" block maintained the best free space information for
-each "data" block. This is not possible with more than one leaf.
+When the ``leaf'' information fills a block, the extents undergo another
+separation. All ``freeindex'' information moves into its own extent. Like Leaf
+Directories, the ``leaf'' block maintained the best free space information for
+each ``data'' block. This is not possible with more than one leaf.
 
-* The "data" blocks stay the same as leaf directories.
+* The ``data'' blocks stay the same as leaf directories.
 
-* After the "freeindex" data moves to its own block, it is possible for the
+* After the ``freeindex'' data moves to its own block, it is possible for the
 leaf data to fit within a single leaf block.  This single leaf block has a
 magic number of +XFS_DIR2_LEAFN_MAGIC+ (0xd2ff).
 
-* The "leaf" blocks eventually change into a B+tree with the generic B+tree
-header pointing to directory "leaves" as described in
+* The ``leaf'' blocks eventually change into a B+tree with the generic B+tree
+header pointing to directory ``leaves'' as described in
 xref:Leaf_Directories[Leaf Directories]. Blocks with leaf data still have the
 +LEAFN_MAGIC+ magic number as outlined above.  The top-level tree blocks are
-called "nodes" and have a magic number of +XFS_DA_NODE_MAGIC+ (0xfebe).
+called ``nodes'' and have a magic number of +XFS_DA_NODE_MAGIC+ (0xfebe).
 
 * Distinguishing between a combined leaf/freeindex block (+LEAF1_MAGIC+), a
 leaf-only block (+LEAFN_MAGIC+), and a btree node block (+NODE_MAGIC+) can only
 be done by examining the magic number.
 
-* The new "freeindex" block(s) only contains the bests for each data block.
+* The new ``freeindex'' block(s) only contains the bests for each data block.
 
 * The freeindex block uses the following structures:
 
@@ -1134,7 +1134,7 @@ typedef struct xfs_dir2_free_hdr {
 ----
 
 *magic*::
-The magic number of the free block, "XD2F" (0x0x58443246).
+The magic number of the free block, ``XD2F'' (0x0x58443246).
 
 *firstdb*::
 The starting directory block number for the bests array.
@@ -1212,7 +1212,7 @@ start of the block.
 block is freed, the data extents contain a hole, and the freeindex's +hdr.nused+
 value is decremented and the associated +bests[]+ entry is set to 0xffff. 
 
-* As the first data block always contains "." and "..", it's invalid for the
+* As the first data block always contains ``.'' and ``..'', it's invalid for the
 directory to have a hole at the start.
 
 * The freeindex's +hdr.nvalid+ should always be the same as the number of
@@ -1297,7 +1297,7 @@ du[5].length = 0x3f50
 du[5].tag = 0
 ----
 
-Next, the "node" block, the fields are preceded with 'n' for node blocks:
+Next, the ``node'' block, the fields are preceded with 'n' for node blocks:
 
 ----
 xfs_db> dblock 8388608
@@ -1409,9 +1409,9 @@ TODO: Example with a hole in the middle
 == B+tree Directories
 
 When the extent map in an inode grows beyond the inode's space, the inode format
-is changed to a "btree". The inode contains a filesystem block point to the
+is changed to a ``btree''. The inode contains a filesystem block point to the
 B+tree extent map for the directory's blocks. The B+tree extents contain the
-extent map for the "data", "node", "leaf", and "freeindex" information as
+extent map for the ``data'', ``node'', ``leaf'', and ``freeindex'' information as
 described in Node Directories.
 
 Refer to the previous section on B+tree xref:Btree_Extent_List[Data Extents] for
diff --git a/design/XFS_Filesystem_Structure/extended_attributes.asciidoc b/design/XFS_Filesystem_Structure/extended_attributes.asciidoc
index 2499f12..f268d66 100644
--- a/design/XFS_Filesystem_Structure/extended_attributes.asciidoc
+++ b/design/XFS_Filesystem_Structure/extended_attributes.asciidoc
@@ -26,8 +26,8 @@ To view extended attributes from the command line, use the +getfattr+ command.
 To set or delete extended attributes, use the +setfattr+ command. ACLs control
 should use the +getfacl+ and +setfacl+ commands.
 
-XFS attributes supports three namespaces: "user", "trusted" (or "root" using
-IRIX terminology), and "secure".
+XFS attributes supports three namespaces: ``user'', ``trusted'' (or ``root'' using
+IRIX terminology), and ``secure''.
 
 See the section about xref:Extended_Attribute_Versions[extended attributes] in
 the inode for instructions on how to calculate the location of the attributes.
@@ -39,7 +39,7 @@ The following four sections describe each of the on-disk formats.
 == Short Form Attributes
 
 When the all extended attributes can fit within the inode's attribute fork, the
-inode's +di_aformat+ is set to "local" and the attributes are stored in the
+inode's +di_aformat+ is set to ``local'' and the attributes are stored in the
 inode's literal area starting at offset +di_forkoff × 8+.
 
 Shortform attributes use the following structures:
@@ -85,9 +85,9 @@ A combination of the following:
 [options="header"]
 |=====
 | Flag				| Description
-| 0                             | The attribute's namespace is "user".
-| +XFS_ATTR_ROOT+		| The attribute's namespace is "trusted".
-| +XFS_ATTR_SECURE+		| The attribute's namespace is "secure".
+| 0                             | The attribute's namespace is ``user''.
+| +XFS_ATTR_ROOT+		| The attribute's namespace is ``trusted''.
+| +XFS_ATTR_SECURE+		| The attribute's namespace is ``secure''.
 | +XFS_ATTR_INCOMPLETE+		| This attribute is being modified.
 | +XFS_ATTR_LOCAL+		| The attribute value is contained within this block.
 |=====
@@ -314,10 +314,10 @@ an inode before they are moved to another filesystem block.
 == Leaf Attributes
 
 When an inode's attribute fork space is used up with shortform attributes and
-more are added, the attribute format is migrated to "extents".
+more are added, the attribute format is migrated to ``extents''.
 
 Extent based attributes use hash/index pairs to speed up an attribute lookup.
-The first part of the "leaf" contains an array of fixed size hash/index pairs
+The first part of the ``leaf'' contains an array of fixed size hash/index pairs
 with the flags stored as well. The remaining part of the leaf block contains the
 array name/value pairs, where each element varies in length.
 
@@ -486,7 +486,7 @@ appropriate structure can be used.
 Since duplicate hash keys are possible, for each hash that matches during a
 lookup, the actual name string must be compared.
 
-An "incomplete" bit is also used for attribute flags. It shows that an attribute
+An ``incomplete'' bit is also used for attribute flags. It shows that an attribute
 is in the middle of being created and should not be shown to the user if we
 crash during the time that the bit is set. The bit is cleared when attribute
 has finished being set up. This is done because some large attributes cannot
@@ -635,7 +635,7 @@ image::images/72.png[]
 
 === xfs_db Node Attribute Example
 
-An inode with 1000 small attributes with the naming "attribute_n" where 'n' is a
+An inode with 1000 small attributes with the naming ``attribute_n'' where 'n' is a
 number:
 
 ----
@@ -677,7 +677,7 @@ The hashes are in ascending order in the btree array, and if the hash for the
 attribute we are looking up is before the entry, we go to the addressed
 attribute block.
 
-For example, to lookup attribute "attribute_267":
+For example, to lookup attribute ``attribute_267'':
 
 ----
 xfs_db> hash attribute_267
@@ -745,7 +745,7 @@ nvlist[84].value = "value_266\d"
 
 Each of the hash entries has +XFS_ATTR_LOCAL+ flag set (1), which means the
 attribute's value follows immediately after the name. Raw disk of the name/value
-pair at offset 2864 (0xb30), highlighted with "value_267\d" following
+pair at offset 2864 (0xb30), highlighted with ``value_267'' following
 immediately after the name:
 
 [subs="quotes"]
@@ -768,7 +768,7 @@ has 2 unused bytes after it.
 == B+tree Attributes
 
 When the attribute's extent map in an inode grows beyond the available space,
-the inode's attribute format is changed to a "btree". The inode contains root
+the inode's attribute format is changed to a ``btree''. The inode contains root
 node of the extent B+tree which then address the leaves that contains the extent
 arrays for the attribute data. The attribute data itself in the allocated
 filesystem blocks use the same layout and structures as described in
diff --git a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc
index a926857..837f025 100644
--- a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc
+++ b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc
@@ -65,7 +65,7 @@ struct xfs_dqblk {
 
 *d_magic*::
 Specifies the signature where these two bytes are 0x4451 (+XFS_DQUOT_MAGIC+),
-or "DQ" in ASCII.
+or ``DQ'' in ASCII.
 
 *d_version*::
 The structure version, currently this is 1 (+XFS_DQUOT_VERSION+).
diff --git a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc
index a887f8e..da6281b 100644
--- a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc
+++ b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc
@@ -15,7 +15,7 @@ image::images/23.png[]
 * The core contains what the inode represents, stat data, and information
 describing the data and attribute forks.
 
-* The +di_u+ "data fork" contains normal data related to the inode. Its contents
+* The +di_u+ ``data fork'' contains normal data related to the inode. Its contents
 depends on the file type specified by +di_core.di_mode+ (eg. regular file,
 directory, link, etc) and how much information is contained in the file which
 determined by +di_core.di_format+. The following union to represent this data is
@@ -34,7 +34,7 @@ union {
 } di_u;
 ----
 
-* The +di_a+ "attribute fork" contains extended attributes. Its layout is
+* The +di_a+ ``attribute fork'' contains extended attributes. Its layout is
 determined by the +di_core.di_aformat+ value. Its representation is declared as
 follows:
 
@@ -54,7 +54,7 @@ within the union are directly cast depending on the +di_mode/di_format+ and
 explain the various structures in use within the inode.
 
 The remaining space in the inode after +di_next_unlinked+ where the two forks
-are located is called the inode's "literal area". This starts at offset 100
+are located is called the inode's ``literal area''. This starts at offset 100
 (0x64) in the inode.
 
 The space for each of the two forks in the literal area is determined by the
@@ -103,7 +103,7 @@ struct xfs_dinode_core {
 ----
 
 *di_magic*::
-The inode signature; these two bytes are 0x494e, or "IN" in ASCII.
+The inode signature; these two bytes are ``IN'' (0x494e).
 
 *di_mode*::
 Specifies the mode access bits and type of file using the standard S_Ixxx values
@@ -117,13 +117,13 @@ converted on the fly to v2 when required.
 
 *di_format*::
 Specifies the format of the data fork in conjunction with the +di_mode+ type.
-This can be one of several values. For directories and links, it can be "local"
-where all metadata associated with the file is within the inode; "extents" where
+This can be one of several values. For directories and links, it can be ``local''
+where all metadata associated with the file is within the inode; ``extents'' where
 the inode contains an array of extents to other filesystem blocks which contain
-the associated metadata or data; or "btree" where the inode contains a B+tree
+the associated metadata or data; or ``btree'' where the inode contains a B+tree
 root node which points to filesystem blocks containing the metadata or data.
 Migration between the formats depends on the amount of metadata associated with
-the inode. "dev" is used for character and block devices while "uuid" is
+the inode. ``dev'' is used for character and block devices while ``uuid'' is
 currently not used.
 
 [source, c]
@@ -171,7 +171,7 @@ Incremented on flush.
 
 Specifies the last access time of the files using UNIX time conventions the
 following structure. This value may be undefined if the filesystem is mounted
-with the "noatime" option.  XFS supports timestamps with nanosecond resolution:
+with the ``noatime'' option.  XFS supports timestamps with nanosecond resolution:
 
 [source, c]
 ----
@@ -226,7 +226,7 @@ details.
 *di_aformat*::
 
 Specifies the format of the attribute fork. This uses the same values as
-+di_format+, but restricted to "local", "extents" and "btree" formats for
++di_format+, but restricted to ``local'', ``extents'' and ``btree'' formats for
 extended attribute data.
 
 *di_dmevmask*::
@@ -312,10 +312,10 @@ image::images/28.png[]
 
 The structure of the inode's data fork based is on the inode's type and
 +di_format+. It always starts at offset 100 (0x64) in the inode's space which is
-the start of the inode's "literal area". The size of the data fork is determined
+the start of the inode's ``literal area''. The size of the data fork is determined
 by the type and format. The maximum size is determined by the inode size and
 +di_forkoff+. In code, use the +XFS_DFORK_PTR+ macro specifying +XFS_DATA_FORK+
-for the "which" parameter. Alternatively, the +XFS_DFORK_DPTR+ macro can be
+for the ``which'' parameter. Alternatively, the +XFS_DFORK_DPTR+ macro can be
 used.
 
 Each of the following sub-sections summarises the contents of the data fork
@@ -403,7 +403,7 @@ does not contain any extended attributes.  If non-zero, the attribute fork's
 byte offset into the literal area can be computed from +di_forkoff × 8+.
 Attributes must be allocated on a 64-bit boundary on the disk. To access the
 extended attributes in code, use the +XFS_DFORK_PTR+ macro specifying
-+XFS_ATTR_FORK+ for the "which" parameter.  Alternatively, the +XFS_DFORK_APTR+
++XFS_ATTR_FORK+ for the ``which'' parameter.  Alternatively, the +XFS_DFORK_APTR+
 macro can be used.
 
 The structure of the attribute fork depends on the +di_aformat+ value
@@ -429,13 +429,13 @@ xref:Extended_Attributes[Extended Attributes] in this document.
 [[Extended_Attribute_Versions]]
 === Extended Attribute Versions
 
-Extended attributes come in two versions: "attr1" or "attr2". The attribute
+Extended attributes come in two versions: ``attr1'' or ``attr2''. The attribute
 version is specified by the +XFS_SB_VERSION2_ATTR2BIT+  flag in the
 +sb_features2+ field in the superblock. It determines how the inode's extra
 space is split between +di_u+ and +di_a+ forks which also determines how the
 +di_forkoff+ value is maintained in the inode's core.
 
-With "attr1" attributes, the +di_forkoff+ is set to somewhere in the middle of
+With ``attr1'' attributes, the +di_forkoff+ is set to somewhere in the middle of
 the space between the core and end of the inode and never changes (which has the
 effect of artificially limiting the space for data information). As the data
 fork grows, when it gets to +di_forkoff+, it will move the data to the next
@@ -443,7 +443,7 @@ format level (ie. local < extent < btree). If very little space is used
 for either attributes or data, then a good portion of the available inode space
 is wasted with this version.
 
-"Attr2" was introduced to maximum the utilisation of the inode's literal area.
+``attr2'' was introduced to maximum the utilisation of the inode's literal area.
 The +di_forkoff+ starts at the end of the inode and works its way to the data
 fork as attributes are added. Attr2 is highly recommended if extended attributes
 are used.
diff --git a/design/XFS_Filesystem_Structure/symbolic_links.asciidoc b/design/XFS_Filesystem_Structure/symbolic_links.asciidoc
index 939c440..5d2c4e8 100644
--- a/design/XFS_Filesystem_Structure/symbolic_links.asciidoc
+++ b/design/XFS_Filesystem_Structure/symbolic_links.asciidoc
@@ -1,15 +1,15 @@
 [[Symbolic_Links]]
 = Symbolic Links
 
-Symbolic links to a file can be stored in one of two formats: "local" and
-"extents". The length of the symlink contents is always specified by the inode's
+Symbolic links to a file can be stored in one of two formats: ``local'' and
+``extents''. The length of the symlink contents is always specified by the inode's
 +di_size+ value.
 
 
 [[Shortform_Symbolic_Links]]
 == Short Form Symbolic Links
 
-Symbolic links are stored with the "local" +di_format+ if the symbolic link can
+Symbolic links are stored with the ``local'' +di_format+ if the symbolic link can
 fit within the inode's data fork. The link data is an array of characters
 (+di_symlink+ array in the data fork union).
 
@@ -58,7 +58,7 @@ xfs_db> p
 
 If the length of the symbolic link exceeds the space available in the inode's
 data fork, the link is moved to a new filesystem block and the inode's
-+di_format+ is changed to "extents". The location of the block(s) is specified
++di_format+ is changed to ``extents''. The location of the block(s) is specified
 by the data fork's +di_bmx[]+ array. In the significant majority of cases, this
 will be in one filesystem block as a symlink cannot be longer than 1024
 characters.