From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id o4CFfK3O170755 for ; Wed, 12 May 2010 10:41:20 -0500 Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8253D13B80C7 for ; Wed, 12 May 2010 08:43:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id AkqyavvUu0H0cEpu for ; Wed, 12 May 2010 08:43:33 -0700 (PDT) Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4CFhWdf016085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 May 2010 11:43:32 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4CFhSbA031032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 May 2010 11:43:31 -0400 Message-ID: <4BEACCA0.3070300@redhat.com> Date: Wed, 12 May 2010 10:43:28 -0500 From: Eric Sandeen MIME-Version: 1.0 Subject: [PATCH] xfsdocs: fix image scaling for pdf List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: xfs-oss Apparently having: format="PNG" width="100%" scalefit="0" in the image attributes is messing up scaling on the pdf such that the images extend beyond the page. (I inherited all that from work our techpubs guy did). On the advice of another techpubs / publican expert, remove it - this seems to fix up the sizing on the pdf build. Signed-off-by: Eric Sandeen --- diff --git a/XFS_Filesystem_Structure/en-US/Allocation_Groups.xml b/XFS_Filesystem_Structure/en-US/Allocation_Groups.xml index a745abe..2831721 100644 --- a/XFS_Filesystem_Structure/en-US/Allocation_Groups.xml +++ b/XFS_Filesystem_Structure/en-US/Allocation_Groups.xml @@ -32,7 +32,7 @@ - + 6 @@ -681,7 +681,7 @@ typedef struct xfs_alloc_rec { The following diagram shows a single level B+tree which consists of one leaf: - + 15a @@ -690,7 +690,7 @@ typedef struct xfs_alloc_rec { With the intermediate nodes, the associated leaf pointers are stored in a separate array about two thirds into the block. The following diagram illustrates a 2-level B+tree for a free space B+tree: - + 15b @@ -709,7 +709,7 @@ typedef struct xfs_alloc_rec { Active elements in the array are specified by the AGF's () agf_flfirst, agf_fllast and agf_flcount values. The array is managed as a circular list. - + 16 @@ -811,7 +811,7 @@ recs[1-344] = [startblock,blockcount] Absolute inode numbers include the AG number in the high bits, above the bits used for the AG relative inode number. Absolute inode numbers are found in directory () entries. - + 18 @@ -913,7 +913,7 @@ typedef __be32 xfs_inobt_ptr_t; The following diagram illustrates a single level inode B+tree: - + 20a @@ -921,7 +921,7 @@ typedef __be32 xfs_inobt_ptr_t; And a 2-level inode B+tree: - + 20b diff --git a/XFS_Filesystem_Structure/en-US/Data_Extents.xml b/XFS_Filesystem_Structure/en-US/Data_Extents.xml index 248ac70..9af8ce7 100644 --- a/XFS_Filesystem_Structure/en-US/Data_Extents.xml +++ b/XFS_Filesystem_Structure/en-US/Data_Extents.xml @@ -9,7 +9,7 @@ An extent is 128 bits in size and uses the following packed layout: - + 30 @@ -62,7 +62,7 @@ typedef enum { - + 32 @@ -111,12 +111,12 @@ u.bmx[0-2] = [startoff,startblock,blockcount,extentflag] Raw disk version of the inode with the third extent highlighted (di_u always starts at offset 0x64): - + code33a We can expand the highlighted section into the following bit array from MSB to LSB with the file offset and the block count highlighted: - + code33b @@ -213,7 +213,7 @@ typedef struct xfs_btree_lblock { - + 35 @@ -240,7 +240,7 @@ typedef struct xfs_btree_lblock { - + diff --git a/XFS_Filesystem_Structure/en-US/Directories.xml b/XFS_Filesystem_Structure/en-US/Directories.xml index 97e2195..e0a7779 100644 --- a/XFS_Filesystem_Structure/en-US/Directories.xml +++ b/XFS_Filesystem_Structure/en-US/Directories.xml @@ -105,7 +105,7 @@ typedef struct xfs_dir2_sf_entry { - + 39 @@ -169,7 +169,7 @@ u.sfdir2.list[3].inumber.i4 = 25165956 The raw data on disk with the first entry highlighted. The six byte header precedes the first entry: - + code40 Next, an entry is deleted (frame000001.tst), and any entries after the deleted entry are moved or compacted to "cover" the hole: @@ -286,7 +286,7 @@ typedef struct xfs_dir2_block_tail { - + 43 @@ -464,7 +464,7 @@ btail.stale = 1 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 highlighted below: - + code46 @@ -536,7 +536,7 @@ typedef struct xfs_da_blkinfo { 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 each data block's bestfree[0].length value. - + 48 @@ -837,7 +837,7 @@ typedef struct xfs_da_intnode { The freeindex's hdr.nvalid should always be the same as the number of allocated data directory blocks containing name/inode data and will always be less than or equal to hdr.nused. hdr.nused should be the same as the index of the last data directory block plus one (i.e. when the last data block is freed, nused and nvalid are decremented). - + 54 @@ -1003,7 +1003,7 @@ fbests[0-4] = 0:0x10 1:0x10 2:0x10 3:0x10 4:0x3f50 Like the Leaf Directory (), each of the fbests values correspond to each data block's bestfree[0].length value. The raw disk layout, old data is not cleared after the array. The fbests array is highlighted: - + code57 TODO: Example with a hole in the middle @@ -1124,7 +1124,7 @@ nbtree[0-318] = [hashval,before] 0:[0x70b14711,8388919] ... The leaves at each the end of a node always point to the end leaves in adjacent nodes. Directory block 8388928 forward pointer is to block 8388919, and vice versa as highlighted in the following example: - + code60 diff --git a/XFS_Filesystem_Structure/en-US/Extended_Attributes.xml b/XFS_Filesystem_Structure/en-US/Extended_Attributes.xml index d0bdb5b..deaa433 100644 --- a/XFS_Filesystem_Structure/en-US/Extended_Attributes.xml +++ b/XFS_Filesystem_Structure/en-US/Extended_Attributes.xml @@ -36,7 +36,7 @@ typedef struct xfs_attr_sf_entry xfs_attr_sf_entry_t; - + 64 @@ -118,7 +118,7 @@ a.sfattr.list[1].value = "val1" We can determine the actual inode offset to be 220 (15 x 8 + 100) or 0xdc. Examining the raw dump, the second attribute is highlighted: - + code65 Adding another attribute with attr1, the format is converted to extents and di_forkoff remains unchanged (and all those zeros in the dump above remain unused): @@ -173,7 +173,7 @@ a.sfattr.list[1].value = "val1" Another attribute is added: - + code66 One more is added: @@ -211,7 +211,7 @@ a.sfattr.list[3].value = "contents" A raw dump is shown to compare with the attr1 dump on a prior page, the header is highlighted: - + code67 It can be clearly seen that attr2 allows many more attributes to be stored in an inode before they are moved to another filesystem block. @@ -280,7 +280,7 @@ typedef struct xfs_attr_leafblock { - + 69 @@ -387,7 +387,7 @@ nvlist[2].name = "big_attr" A raw disk dump shows the attributes. The last attribute added is highlighted (offset 4044 or 0xfcc): - + c @@ -410,7 +410,7 @@ nvlist[2].name = "big_attr" - + 72 @@ -467,12 +467,12 @@ xfs_db> hash attribute_267 In the root btree node, this falls between 0x3437922e and 0x3437d22a, therefore leaf 11 or attribute block 5 will contain the entry. - + code73-74 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 immediately after the name: - + code74 Each entry starts on a 32-bit (4 byte) boundary, therefore the highlighted entry has 2 unused bytes after it. diff --git a/XFS_Filesystem_Structure/en-US/Internal_Inodes.xml b/XFS_Filesystem_Structure/en-US/Internal_Inodes.xml index b42a4a8..ac82884 100644 --- a/XFS_Filesystem_Structure/en-US/Internal_Inodes.xml +++ b/XFS_Filesystem_Structure/en-US/Internal_Inodes.xml @@ -23,7 +23,7 @@ - + 76 diff --git a/XFS_Filesystem_Structure/en-US/On-disk_Inode.xml b/XFS_Filesystem_Structure/en-US/On-disk_Inode.xml index 9acdc8e..5b7c926 100644 --- a/XFS_Filesystem_Structure/en-US/On-disk_Inode.xml +++ b/XFS_Filesystem_Structure/en-US/On-disk_Inode.xml @@ -8,7 +8,7 @@ An inode is divided into 3 parts: - + 23 @@ -344,7 +344,7 @@ typedef struct xfs_timestamp { - + 28 @@ -431,7 +431,7 @@ typedef struct xfs_timestamp { The following diagram compares the two versions: - + 30 diff --git a/XFS_Filesystem_Structure/en-US/Symbolic_Links.xml b/XFS_Filesystem_Structure/en-US/Symbolic_Links.xml index 9ef09ed..76c69a5 100644 --- a/XFS_Filesystem_Structure/en-US/Symbolic_Links.xml +++ b/XFS_Filesystem_Structure/en-US/Symbolic_Links.xml @@ -10,7 +10,7 @@ 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). - + 61 @@ -36,7 +36,7 @@ u.symlink = "small_target" Raw on-disk data with the link contents highlighted: - + code61 @@ -48,7 +48,7 @@ u.symlink = "small_target" - + 62 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs