On Wed, Aug 10, 2022 at 12:53:26PM +0200, Carlos Maiolino wrote:
> Cleanup xfsdump.html and remove all trailing white spaces from it.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
> ---
> doc/xfsdump.html | 408 +++++++++++++++++++++++++++---------------------------
> po/de.po | 4 -
> 2 files changed, 206 insertions(+), 206 deletions(-)
>
> diff --git a/doc/xfsdump.html b/doc/xfsdump.html
> index 958bc80..e37e362 100644
> --- a/doc/xfsdump.html
> +++ b/doc/xfsdump.html
> @@ -29,8 +29,8 @@
> <ul>
> <li><a href="#main">The main function of xfsdump</a>
> <ul>
> - <li><a href="#drive_init1">drive_init1</a>
> - <li><a href="#content_init_dump">content_init</a>
> + <li><a href="#drive_init1">drive_init1</a>
> + <li><a href="#content_init_dump">content_init</a>
> </ul>
> <li><a href="#dump_tape">Dumping to Tape</a>
> <ul>
> @@ -86,7 +86,7 @@ These notes are written for xfsdump and xfsrestore in IRIX. Therefore,
> it refers to some features that aren't supported in Linux.
> For example, the references to multiple streams/threads/drives do not
> pertain to xfsdump/xfsrestore in Linux. Also, the DMF support in xfsdump
> -is not yet useful for Linux.
> +is not yet useful for Linux.
>
> <hr>
> <h3><a name="intro">What's in a dump</a></h3>
> @@ -95,7 +95,7 @@ or stdout. The dump includes all the filesystem objects of:
> <ul>
> <li>directories (S_IFDIR)
> <li>regular files (S_IFREG)
> -<li>sockets (S_IFSOCK)
> +<li>sockets (S_IFSOCK)
> <li>symlinks (S_IFLNK)
> <li>character special files (S_IFCHR)
> <li>block special files (S_IFBLK)
> @@ -106,7 +106,7 @@ xfsdump inventory is located.
> Other data which is stored:
> <ul>
> <li> file attributes (stored in stat data) of owner, group, permissions,
> -and date stamps
> +and date stamps
> <li> any extended attributes associated with these file objects
> <li> extent information is stored allowing holes to be reconstructed
> on restoral
> @@ -137,7 +137,7 @@ believe that only one media-file is used. Whereas on tape
> media, multiple media files are used depending upon the size
> of the media file. The size of the media file is set depending
> on the drive type (in IRIX): QIC: 50Mb; DAT: 512Mb; Exabyte: 2Gb; DLT: 4Gb;
> -others: 256Mb. This value (media file size) is now able to be changed
> +others: 256Mb. This value (media file size) is now able to be changed
> by the "-d" option.
> . Also, on tape, the dump is finished by an inventory
> media file followed by a terminating null media file.
> @@ -188,16 +188,16 @@ pad to 1K bytes
> strategy id = on-file, on-tape, on-rmt-tape
> strategy specific data:
> field to denote if media file is a terminator (old fmt)
> - upper: (to 2K)
> + upper: (to 2K)
> </pre>
>
> <p>
> Note that the <i>strategy id</i> is checked on restore so that
> -the dump strategy and the strategy used by restore
> -are the same with the exception that drive_scsitape matches with
> -drive_minrmt. This strategy check has caused problems with customers
> +the dump strategy and the strategy used by restore
> +are the same with the exception that drive_scsitape matches with
> +drive_minrmt. This strategy check has caused problems with customers
> in the past.
> -In particular, if one sends xfsdump's stdout to a tape
> +In particular, if one sends xfsdump's stdout to a tape
> (i.e. xfsdump -L test -M test - / >/dev/tape) then one can not
> restore this tape using xfsrestore by specifying the tape with the -f option.
> There was also a problem for a time where if one used a drive with
> @@ -205,7 +205,7 @@ the TS tape driver, xfsdump wouldn't recognise this driver and
> would select the drive_simple strategy.
>
> <hr>
> -
> +
>
> <h4><a name="inode_map">Inode Map</a></h4>
> <img src="inode_map.gif">
> @@ -227,8 +227,8 @@ then the file can be dumped in multiple records or extent groups.
> <h3><a name="tape_format">Format on Tape</a></h3>
> At the beginning of each tape record is a header. However, for
> the first record of a media file, the record header is buried
> -inside the global header at byte offset 1536 (1K + 512), as is shown in
> -the global header diagram.
> +inside the global header at byte offset 1536 (1K + 512), as is shown in
> +the global header diagram.
> Reproduced again:
> <pre>
> <b>rec_hdr</b>
> @@ -246,28 +246,28 @@ dump uuid
> pad to 512 bytes
> </pre>
> <p>
> -I can not see where the block-size ("tape_blksz") is ever used !
> +I can not see where the block-size ("tape_blksz") is ever used !
> The record-size ("tape_recsz") is used as the byte count to do
> the actual write and read system calls.
> <p>
> There is another layer of s/ware for the actual data on the tape.
> Although, one may write out an inode-map or directory entries,
> -one doesn't just give these record buffers straight to the
> +one doesn't just give these record buffers straight to the
> write system call to write out. Instead, these data objects are
> written to buffers (akin to <stdio>). Another thread reads
> from these buffers (unless its running single-threaded) and writes
> them to tape.
> Specifically, inside a loop,
> one calls <b>do_get_write_buf</b>,
> -copies over the data one wants stored and then
> +copies over the data one wants stored and then
> calls <b>do_write_buf</b>, until the entire data buffer
> has been copied over.
>
> -<hr>
> +<hr>
>
> <h3><a name="run_time_structure">Run Time Structure</a></h3>
>
> -This section reviews the run time structure and failure handling in
> +This section reviews the run time structure and failure handling in
> dump/restore (see IRIX PV 784355).
>
> The diagram below gives a schematic of the runtime structure
> @@ -346,7 +346,7 @@ point they drop out of the message processing loop and always signal success.
> <p>
> Thus the only child processes that can affect the return status of
> dump or restore are the stream managers, and these processes take
> -their exit status from the values returned by
> +their exit status from the values returned by
> <b>content_stream_dump</b> and <b>content_stream_restore</b>.
>
> <hr>
> @@ -374,14 +374,14 @@ create inode-ranges for multi-stream dumps if pertinent.
> The inode map stores the type of the inode: directory or non-directory,
> and a state value to say whether it has changed or not.
> The inode map is built by processing each inode (using bulkstat) and
> - in order to work out if it should be marked as changed,
> + in order to work out if it should be marked as changed,
> by comparing its date stamp with the date of the base or interrupted
> - dump.
> + dump.
> We also update the size for non-dir regular files (bs_blocks * bs_blksize)
> <li><b>phase 3</b>: prune the unneeded subtrees due to the set of
> unchanged directories or the subtrees specified in -s (phase 1).
> - This works by marking higher level directories as unchanged
> - (MAP_DIR_NOCHNG) in the inode map.
> + This works by marking higher level directories as unchanged
> + (MAP_DIR_NOCHNG) in the inode map.
> <li><b>phase 4</b>: estimate non-dir (file) size if pruning was done
> since phase 2.
> It calculates this by processing each inode (using bulkstat)
> @@ -389,7 +389,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> If it is then it uses (bs_blocks * bs_blksize) as in phase 2.
> <li><b>phase 5</b>: if we have multiple streams, then
> it splits up the dump to try to give each stream a set of inodes
> - which has an equal amount of file data.
> + which has an equal amount of file data.
> See the section on "Splitting a dump over multiple streams" below.
> </ul>
>
> @@ -428,13 +428,13 @@ create inode-ranges for multi-stream dumps if pertinent.
> <li> end the media file
> <li> update online inventory
> </ul>
> -<li> if multiple-media dump (i.e. tape dump and not file dump) then
> +<li> if multiple-media dump (i.e. tape dump and not file dump) then
> <ul>
> <li> dump the session inventory to a media file
> <li> dump the terminator to a media file
> </ul>
> </ul>
> -
> +
> <hr>
>
> <h5><a name="main">The main function of xfsdump</a></h5>
> @@ -442,7 +442,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> <pre>
> * <b><a name="drive_init1">drive_init1</a></b> - initialize drive manager for each stream
> - go thru cmd options looking for -f device
> - - each device requires a drive-manager and hence an sproc
> + - each device requires a drive-manager and hence an sproc
> (sproc = IRIX lightweight process)
> - if supposed to run single threaded then can only
> support one device
> @@ -452,7 +452,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - if "-" specified for std out then only one drive allowed
>
> - for each drive it tries to pick best strategy manager
> - - there are 3 strategies
> + - there are 3 strategies
> 1) simple - for dump on file
> 2) scsitape - for dump on tape
> 3) minrmt - minimal protocol for remote tape (non-SGI)
> @@ -470,7 +470,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - note if remote tape (has ":" in name)
> - set capabilities of BSF, FSF, etc.
>
> -* <b>create global header</b>
> +* <b>create global header</b>
> - store magic#, version, date, hostid, uuid, hostname
> - process args for session-id, dump-label, ...
>
> @@ -481,13 +481,13 @@ create inode-ranges for multi-stream dumps if pertinent.
>
> * inomap_build() - stores stream start-points and builds inode map
>
> - - <b>phase1</b>: parsing subtree selections (specified by -s options)
> - <b>INPUT</b>:
> + - <b>phase1</b>: parsing subtree selections (specified by -s options)
> + <b>INPUT</b>:
> - sub directory entries (from -s)
> <b>FLOW</b>:
> - - go thru each subtree and
> + - go thru each subtree and
> call diriter(callback=subtreelist_parse_cb)
> - - diriter on subtreelist_parse_cb
> + - diriter on subtreelist_parse_cb
> - open_by_handle() on dir handle
> - getdents()
> - go thru each entry
> @@ -503,9 +503,9 @@ create inode-ranges for multi-stream dumps if pertinent.
> - list of inodes corresponding to subtree path names
>
> - premptchk: progress report, return if got a signal
> -
> +
> - <b>phase2</b>: creating inode map (initial dump list)
> - <b>INPUT</b>:
> + <b>INPUT</b>:
> - bulkstat records on all the inodes in the file system
> <b>FLOW</b>:
> - bigstat_init on cb_add()
> @@ -516,16 +516,16 @@ create inode-ranges for multi-stream dumps if pertinent.
> - loop thru each struct xfs_bstat record for an inode
> calling cb_add()
> * cb_add
> - - looks at latest mtime|ctime and
> + - looks at latest mtime|ctime and
> if inode is resumed:
> - compares with cb_resumetime for change
> + compares with cb_resumetime for change
> if have cb_last:
> compares with cb_lasttime for change
> - add inode to map (map_add) and note if has changed or not
> - - call with state of either
> + - call with state of either
> changed - MAP_DIR_CHANGE, MAP_NDR_CHANGE
> not changed - MAP_DIR_SUPPRT or MAP_NDR_NOCHNG
> - - for changed non-dir REG inode,
> + - for changed non-dir REG inode,
> data size for its dump is added by bs_blocks * bs_blksize
> - for non-changed dir, it sets flag for <pruneneeded>
> => we don't want to process this later !
> @@ -533,31 +533,31 @@ create inode-ranges for multi-stream dumps if pertinent.
> - segment = <base, 64-low, 64-mid, 64-high>
> = like 64 * 3-bit values (use 0-5)
> i.e. for 64 inodes, given start inode number
> - #define MAP_INO_UNUSED 0 /* ino not in use by fs -
> + #define MAP_INO_UNUSED 0 /* ino not in use by fs -
> Used for lookup failure */
> - #define MAP_DIR_NOCHNG 1 /* dir, ino in use by fs,
> + #define MAP_DIR_NOCHNG 1 /* dir, ino in use by fs,
> but not dumped */
> - #define MAP_NDR_NOCHNG 2 /* non-dir, ino in use by fs,
> + #define MAP_NDR_NOCHNG 2 /* non-dir, ino in use by fs,
> but not dumped */
> #define MAP_DIR_CHANGE 3 /* dir, changed since last dump */
>
> #define MAP_NDR_CHANGE 4 /* non-dir, changed since last dump */
>
> - #define MAP_DIR_SUPPRT 5 /* dir, unchanged
> + #define MAP_DIR_SUPPRT 5 /* dir, unchanged
> but needed for hierarchy */
> - hunk = 4 pages worth of segments, max inode#, next ptr in list
> - i.e. map = linked list of 4 pages of segments of 64 inode states
> <b>OUTPUT</b>:
> - - inode map = list of all inodes of file system and
> + - inode map = list of all inodes of file system and
> for each one there is an associated state variable
> describing type of inode and whether it has changed
> - - the inode numbers are stored in chunks of 64
> + - the inode numbers are stored in chunks of 64
> (with only the base inode number explicitly stored)
>
> - premptchk: progress report, return if got a signal
>
> - if <pruneneeded> (i.e. non-changed dirs) OR subtrees specified (-s)
> - - <b>phase3</b>: pruning inode map (pruning unneeded subtrees)
> + - <b>phase3</b>: pruning inode map (pruning unneeded subtrees)
> <b>INPUT</b>:
> - subtree list
> - inode map
> @@ -565,13 +565,13 @@ create inode-ranges for multi-stream dumps if pertinent.
> - bigstat_iter on cb_prune() per inode
> * cb_prune
> - if have subtrees and subtree list contains inode
> - -> need to traverse every group (inogrp_t) and
> + -> need to traverse every group (inogrp_t) and
> every page of inode#s
> - diriter on cb_count_in_subtreelist
> * cb_count_in_subtreelist:
> - looks up each inode# (in directory iteration) in subtreelist
> - if exists then increment counter
> - - if at least one inode in list
> + - if at least one inode in list
> - diriter on cb_cond_del
> * cb_cond_del:
> - TODO
> @@ -629,20 +629,20 @@ create inode-ranges for multi-stream dumps if pertinent.
> - header = <offset, flags, checksum, 128-byte bulk stat structure >
> - bulkstat struct derived from struct xfs_bstat
> - stnd. stat stuff + extent size, #of extents, DMI stuff
> - - if HSM context then
> + - if HSM context then
> - modify bstat struct to make it offline
> - loops calling getdents()
> - - does a bulkstat or bulkstat-single of dir inode
> + - does a bulkstat or bulkstat-single of dir inode
> * dump_dirent()
> - fill in direnthdr_t record
> - - <ino, gen & DENTGENMASK, record size,
> + - <ino, gen & DENTGENMASK, record size,
> checksum, variable length name (8-char padded)>
> - gen is from statbuf.bs_gen
> - - write out record
> + - write out record
> - dump null direnthdr_t record
> - - if dumpextattr flag on and it
> + - if dumpextattr flag on and it
> has extended attributes (check bs_xflags)
> - * dump_extattrs
> + * dump_extattrs
> * dump_filehdr() with flags of FILEHDR_FLAGS_EXTATTR
> - for root and non-root attributes
> - get attribute list (attr_list_by_handle())
> @@ -650,7 +650,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - TODO
>
> - bigstat iter on dump_file()
> - - go thru each inode in file system and apply dump_file
> + - go thru each inode in file system and apply dump_file
> * dump_file()
> - if file's inode# is less than the start-point then skip it
> -> presume other sproc handling dumping of that inode
> @@ -658,7 +658,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - look-up inode# in inode map
> - if not in inode-map OR hasn't changed then skip it
> - elsif stat is NOT a non-dir then we have an error
> - - if have an hsm context then initialize context
> + - if have an hsm context then initialize context
> - call dump function depending on file type (S_IFREG, S_IFCHR, etc.)
>
> * <b>dump_file_reg</b> (for S_IFREG):
> @@ -671,7 +671,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - dump extent header of type, EXTENTHDR_TYPE_DATA
> - write out link buffer (i.e. symlink string)
>
> - - if dumpextattr flag on and it
> + - if dumpextattr flag on and it
> has extended attributes (check bs_xflags)
> * dump_extattrs (see the same call in the dir case above)
>
> @@ -686,7 +686,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - if got an inventory stream then
> * inv_put_mediafile
> - create an inventory-media-file struct (invt_mediafile_t)
> - - < media-obj-id, label, index, start-ino#, start-offset,
> + - < media-obj-id, label, index, start-ino#, start-offset,
> end-ino#, end-offset, size = #recs in media file, flag >
> * stobj_put_mediafile
>
> @@ -694,7 +694,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - lock and increment the thread done count
>
> - if dump supports multiple media files (tapes do but dump-files don't) then
> - - if multi-threaded then
> + - if multi-threaded then
> - wait for all threads to have finished dumping
> (loops sleeping for 1 second each iter)
> * dump_session_inv
> @@ -716,9 +716,9 @@ create inode-ranges for multi-stream dumps if pertinent.
> * <b><a name="dump_file_reg">dump_file_reg</a></b> (for S_IFREG):
> - if this is the start inode, then set the start offset
> - fixup offset for resumed dump
> - * init_extent_group_context
> + * init_extent_group_context
> - init context - reset getbmapx struct fields with offset=0, len=-1
> - - open file by handle
> + - open file by handle
> - ensure Mandatory lock not set
> - loop dumping extent group
> - dump file header
> @@ -739,11 +739,11 @@ create inode-ranges for multi-stream dumps if pertinent.
>
> - if bmap entry is a hole (bmv_block == -1) then
> - if dumping ext.attributes then
> - - dump extent header with bmap's offset,
> + - dump extent header with bmap's offset,
> extent-size and type EXTENTHDR_TYPE_HOLE
>
> - move onto next bmap
> - - if bmap's (offset + len)*512 > next-offset then
> + - if bmap's (offset + len)*512 > next-offset then
> update next-offset to this
> - inc ptr
>
> @@ -767,7 +767,7 @@ create inode-ranges for multi-stream dumps if pertinent.
> - read data of actualsz from file into buffer
> - write out buffer
> - if at end of file and have left over space in the extent then
> - - pad out the rest of the extent
> + - pad out the rest of the extent
> - if next offset is at or past next-bmap's offset+len then
> - move onto next bmap
> - dump null extent header of type, EXTENTHDR_TYPE_LAST
> @@ -779,10 +779,10 @@ create inode-ranges for multi-stream dumps if pertinent.
> <hr>
>
> <h4><a name="reg_split">Splitting a Regular File</a></h4>
> -If a regular file is greater than 16Mb
> -(maxextentcnt = drivep->d_recmarksep
> - = recommended max. separation between marks),
> -then it is broken up into multiple extent groups each with their
> +If a regular file is greater than 16Mb
> +(maxextentcnt = drivep->d_recmarksep
> + = recommended max. separation between marks),
> +then it is broken up into multiple extent groups each with their
> own filehdr_t's.
> A regular file can also be split, if we are dumping to multiple
> streams and the file would span the stream boundary.
> @@ -790,15 +790,15 @@ streams and the file would span the stream boundary.
> <h4><a name="split_mstream">Splitting a dump over multiple streams (Phase 5)</a></h4>
> If one is dumping to multiple streams, then xfsdump calculates an
> estimate of the dump size and divides by the number of streams to
> -determine how much data we should allocate for a stream.
> -The inodes are processed in order from <i>bulkstat</i> in the function
> +determine how much data we should allocate for a stream.
> +The inodes are processed in order from <i>bulkstat</i> in the function
> <i>cb_startpt</i>. Thus we start allocating inodes to the first stream
> until we reach the allocated amount and then need to decide how to
> proceed on to the next stream. At this point we have 3 actions:
> <dl>
> <dt>Hold
> <dd>Include this file in the current stream.
> -<dt>Bump
> +<dt>Bump
> <dd>Start a new stream beginning with this file.
> <dt>Split
> <dd>Split this file across 2 streams in different extent groups.
> @@ -850,8 +850,8 @@ Initialize the mmap files of:
> <li> search for directory dump
> <li> calls <b>dirattr_init</b> if necessary
> <li> calls <b>namreg_init</b> if necessary
> - <li> initialize the directory tree (<b>tree_init</b>)
> - <li> read the dirents into the tree
> + <li> initialize the directory tree (<b>tree_init</b>)
> + <li> read the dirents into the tree
> (<a href="#applydirdump"><b>applydirdump</b></a>)
> </ul>
>
> @@ -866,17 +866,17 @@ Initialize the mmap files of:
>
> <li> all threads can process each media file of their dumps for
> restoring the non-directory files
> - <ul>
> - <li>loop over each media file
> + <ul>
> + <li>loop over each media file
> <ul>
> <li> read in file header
> - <li> call <b>applynondirdump</b> for file hdr
> - <ul>
> - <li> restore extended attributes for file
> - (if it is last extent group of file)
> + <li> call <b>applynondirdump</b> for file hdr
> + <ul>
> + <li> restore extended attributes for file
> + (if it is last extent group of file)
> <li> restore file
> <ul>
> - <li>loop thru all hardlink paths from tree for inode
> + <li>loop thru all hardlink paths from tree for inode
> (<b>tree_cb_links</b>) and call <b>restore_file_cb</b>
> <ul>
> <li> if a hard link then link(path1, path2)
> @@ -890,11 +890,11 @@ Initialize the mmap files of:
> <li>set DMAPI fields if necessary
> <li>loop processing the extent headers
> <ul>
> - <li>if type LAST then exit loop
> + <li>if type LAST then exit loop
> <li>if type ALIGN then eat up the padding
> <li>if type HOLE then ignore
> - <li>if type DATA then copy the data into
> - the file for the extent;
> + <li>if type DATA then copy the data into
> + the file for the extent;
> seeking to extent start if necessary
> </ul>
> <li>register the extent group in the partial registry
> @@ -917,9 +917,9 @@ Initialize the mmap files of:
> <li> if corrupt then go to next mark
> <li> else exit loop
> </ul>
> - </ul>
> + </ul>
> </ul>
> - </ul>
> + </ul>
>
> <li> one stream does while others wait:
> <ul>
> @@ -937,7 +937,7 @@ Initialize the mmap files of:
> <b>content_init</b> in a bit more detail(xfsrestore version)
> <ul>
> <li> create house-keeping-directory for persistent mmap file data
> - structures. For cumulative and interrupted restores,
> + structures. For cumulative and interrupted restores,
> we need to keep restore session data between invocations of xfsrestore.
> <li> mmap the "state" file and create if not already existing.
> Initially just mmap the header. (More details below)
> @@ -969,14 +969,14 @@ Initialize the mmap files of:
> <h4><a name="pers_inv">Persistent Inventory and State File</a></h4>
>
> The persistent inventory is found inside the "state" file.
> -The state file is an mmap'ed file called
> +The state file is an mmap'ed file called
> <b>$dstdir/xfsrestorehousekeepingdir/state</b>.
> -The state file (<i>struct pers</i> from content.c) contains
> +The state file (<i>struct pers</i> from content.c) contains
> a header of:
> <ul>
> <li>command line arguments from 1st session,
> <li>partial registry data structure for use with multiple streams
> - and extended attributes,
> + and extended attributes,
> <li>various session state such as
> dumpid, dump label, number of inodes restored so far, etc.
> </ul>
> @@ -1054,7 +1054,7 @@ tree of directory nodes. This tree can then be used to associate
> the file with it's directory and so restored to the correct location
> in the directory structure.
> <p>
> -The tree is an mmap'ed file called
> +The tree is an mmap'ed file called
> <b>$dstdir/xfsrestorehousekeepingdir/tree</b>.
> Different sections of it will be mmap'ed separately.
> It is of the following format:
> @@ -1098,7 +1098,7 @@ chained hash table with the "next" link stored in the tree node
> in the <i>n_hashh</i> field of struct node in restore/tree.c.
> The size of the hash table is based on the number of directories
> and non-directories (which will approximate the number of directory
> -entries - won't include extra hard links). The size of the table
> +entries - won't include extra hard links). The size of the table
> is capped below at 1 page and capped above at virtual-memory-limit/4/8
> (i.e. vmsz/32) or the range of 2^32 whichever is the smaller.
> <p>
> @@ -1157,15 +1157,15 @@ each node using the first 8 bytes (ignoring node fields).
> | | | |
> | | 8192 | |
> | | nodes| | nodes already used in tree
> -| | used | |
> -| | | |
> +| | used | |
> +| | | |
> | |------| |
> | |
> -| |------| |
> +| |------| |
> | | --------| <-----nh_freenix (ptr to node-freelist)
> | |node1 | | |
> -| |------| | | node-freelist (linked list of free nodes)
> -| | ----<---|
> +| |------| | | node-freelist (linked list of free nodes)
> +| | ----<---|
> | |node2 | |
> | |------| |
> ............
> @@ -1176,7 +1176,7 @@ each node using the first 8 bytes (ignoring node fields).
>
>
> <h5><a name="win_abs">Window Abstraction</a></h5>
> -The window abstraction manages the mapping and unmapping of the
> +The window abstraction manages the mapping and unmapping of the
> segments (of nodes) of the dirent tree.
> In the node allocation, mentioned above, if our node-freelist is
> empty we call <i><b>win_map()</b></i> to map in a chunk of 8192 nodes
> @@ -1185,8 +1185,8 @@ for the node-freelist.
> Consider the <i><b>win_map</b>(offset, return_memptr)</i> function:
> <pre>
> One is asking for an offset within a segment.
> -It looks up its <i>bag</i> for the segment (given the offset), and
> -if it's already mapped then
> +It looks up its <i>bag</i> for the segment (given the offset), and
> +if it's already mapped then
> if the window has a refcnt of zero, then remove it from the win-freelist
> it uses that address within the mmap region and
> increments refcnt.
> @@ -1194,7 +1194,7 @@ else if it's not in the bag then
> if win-freelist is not empty then
> munmap the oldest mapped segment
> remove head of win-freelist
> - remove the old window from the bag
> + remove the old window from the bag
> else /* empty free-list */
> allocate a new window
> endif
> @@ -1214,9 +1214,9 @@ in the node allocation.
> Note that the windows are stored in 2 lists. They are doubly
> linked in the LRU win-freelist and are also stored in a <i>bag</i>.
> A bag is just a doubly linked searchable list where
> -the elements are allocated using <i>calloc()</i>.
> +the elements are allocated using <i>calloc()</i>.
> It uses the bag as a container of mmaped windows which can be
> -searched using the bag key of window-offset.
> +searched using the bag key of window-offset.
> <pre>
>
> BAG: |--------| |--------| |--------| |--------| |-------|
> @@ -1239,7 +1239,7 @@ win-freelist: | oldest | | 2nd |
> <p>
> <b>Call Chain</b><br>
>
> -Below are some call chain scenarios of how the allocation of
> +Below are some call chain scenarios of how the allocation of
> dirent tree nodes are done at different stages.
> <p>
> <pre>
> @@ -1269,7 +1269,7 @@ applydirdump()
> node_alloc()
> get node off node-freelist (8190 nodes left now)
> return node
> -
> +
> 8193th time when we have used up 8192 nodes and node-freelist is emtpy:
>
> if new entry then
> @@ -1282,13 +1282,13 @@ applydirdump()
> refcnt++
> return addr
> make a node-freelist of 8192 nodes from where left off last time
> - win_unmap
> + win_unmap
> refcnt--
> put on LRU win-freelist as refcnt==0
> get node off node-freelist (8191 nodes left now)
> return node
> -
> -When whole segment used up and thus all remaining node-freelist
> +
> +When whole segment used up and thus all remaining node-freelist
> nodes are gone then
> (i.e. in old scheme would have used up all 1 million nodes
> from first segment):
> @@ -1332,7 +1332,7 @@ and adding to the tree and other auxiliary structures:
>
> <a name="applydirdump"><b>applydirdump</b>()</a>
> ...
> - inomap_restore_pers() - read ino map
> + inomap_restore_pers() - read ino map
> read directories and their entries
> loop 'til null hdr
> dirh = <b>tree_begindir</b>(fhdr, dah) - process dir filehdr
> @@ -1352,7 +1352,7 @@ and adding to the tree and other auxiliary structures:
> new directory - 1st time seen
> dah = dirattr_add(fhdrp) - add dir header to dirattr structure
> hardh = Node_alloc(ino, gen,....,NF_ISDIR|NF_NEWORPH)
> - link_in(hardh) - link into tree
> + link_in(hardh) - link into tree
> adopt(p_orphh, hardh, NRH_NULL) - put dir in orphanage directory
> else
> ...
> @@ -1379,12 +1379,12 @@ and adding to the tree and other auxiliary structures:
> A cumulative restore seems a bit different than one might expect.
> It tries to restore the state of the filesystem at the time of
> the incremental dump. As the man page states:
> -"This can involve adding, deleting, renaming, linking,
> +"This can involve adding, deleting, renaming, linking,
> and unlinking files and directories." From a coding point of view,
> this means we need to know what the dirent tree was like previously
> compared with what the dirent tree is like now. We need this so
> -we can see what was added and deleted. So this means that the
> -dirent tree, which is stored as an mmap'ed file in
> +we can see what was added and deleted. So this means that the
> +dirent tree, which is stored as an mmap'ed file in
> <i>restoredir/xfsrestorehousekeepingdir/tree</i> should not be deleted
> between cumulative restores (as we need to keep using it).
> <p>
> @@ -1396,8 +1396,8 @@ dirents, it looks them up in the tree (created on previous restore).
> If the entry alreadys exists then it marks it as <i>NF_REFED</i>.
> <p>
> In case a dirent has gone away between times of incremental dumps,
> -xfsrestore does an extra pass in the tree preprocessing
> -which traverses the tree looking for non-referenced (not <i>NF_REFED</i>)
> +xfsrestore does an extra pass in the tree preprocessing
> +which traverses the tree looking for non-referenced (not <i>NF_REFED</i>)
> nodes so that if they exist in the FS (i.e. are <i>NF_REAL</i>) then
> they can be deleted (so that the FS resembles what it was at the time
> of the incremental dump).
> @@ -1418,7 +1418,7 @@ cumulative restoral, it does a 4 step postprocessing (<b>treepost</b>):
> <td><b>1. noref_elim_recurse</b></td>
> <td><ul>
> <li>remove deleted dirs
> - <li>rename moved dirs to orphanage
> + <li>rename moved dirs to orphanage
> <li>remove extra deleted hard links
> <li>rename moved non-dirs to orphanage
> </ul></td>
> @@ -1443,7 +1443,7 @@ cumulative restoral, it does a 4 step postprocessing (<b>treepost</b>):
> <li>create a link on rename error (don't understand this one)
> </ul></td>
> </tr>
> -</table>
> +</table>
>
> <p>
> Step 1 was changed so that files which are deleted and not moved
> @@ -1459,13 +1459,13 @@ The new step is:
> <td><b>1. noref_elim_recurse</b></td>
> <td><ul>
> <li>remove deleted dirs
> - <li>rename moved dirs to orphanage
> + <li>rename moved dirs to orphanage
> <li>remove extra deleted hard links
> <li>rename moved non-dirs to orphanage
> <li>remove deleted non-dirs which aren't part of a rename
> </ul></td>
> </tr>
> -</table>
> +</table>
> <p>
> One will notice that renames are not performed directly.
> Instead entries are renamed to the orphanage, directories are
> @@ -1481,12 +1481,12 @@ should not happen now since it is done earlier.
> <hr>
> <h4><a name="partial_reg">Partial Registry</a></h4>
>
> -The partial registry is a data structure used in <i>xfsrestore</i>
> -for ensuring that files which have been split into multiple extent groups,
> +The partial registry is a data structure used in <i>xfsrestore</i>
> +for ensuring that files which have been split into multiple extent groups,
> do not restore the extended attributes until the entire file has been
> restored. The reason for this is apparently so that DMAPI attributes
> aren't restored until we have the complete file. Each extent group dumped
> -has the identical copy of the extended attributes (EAs) for that file,
> +has the identical copy of the extended attributes (EAs) for that file,
> thus without this data-structure we could apply the first EAs we come across.
> <p>
> The data structure is of the form:
> @@ -1535,8 +1535,8 @@ then the extent range for this file is updated with the partial
> registry. If the file doesn't exist in the array then a new entry is
> added. If the file does exist in the array then the extent group for
> the given drive is updated. It is worth remembering that one drive
> -(stream) can have multiple extent groups (if it is >16Mb) in which
> -case the extent group is just extended (they are split up in order).
> +(stream) can have multiple extent groups (if it is >16Mb) in which
> +case the extent group is just extended (they are split up in order).
> <p>
> A bug was discovered in this area of code, for <i>DMF offline</i> files
> which have an associated file size but no data blocks allocated and
> @@ -1550,7 +1550,7 @@ restore data are now special cased.
>
> <h3><a name="drive_strategy">Drive Strategies</a></h3>
> The I/O which happens when reading and writing the dump
> -can be to a tape, file, stdout or
> +can be to a tape, file, stdout or
> to a tape remotely via rsh(1) (or $RSH) and rmt(1) (or $RMT).
> There are 3 pieces of code called strategies which
> handle the dump I/O:
> @@ -1600,8 +1600,8 @@ The scoring function is called ds_match.
> with path (not available on Linux), score -10 if the following:
> <ul>
> <li>stat fails
> - <li>it is not a character device
> - <li>its real path does not contain "/nst", "/st" nor "/mt".
> + <li>it is not a character device
> + <li>its real path does not contain "/nst", "/st" nor "/mt".
> </ul>
> </td>
> </tr>
> @@ -1644,29 +1644,29 @@ The scoring function is called ds_match.
> Each strategy is organised like a "class" with functions/methods
> in the data structure:
> <pre>
> - do_init,
> - do_sync,
> - do_begin_read,
> - do_read,
> - do_return_read_buf,
> - do_get_mark,
> - do_seek_mark,
> - do_next_mark,
> - do_end_read,
> - do_begin_write,
> - do_set_mark,
> - do_get_write_buf,
> - do_write,
> - do_get_align_cnt,
> - do_end_write,
> - do_fsf,
> - do_bsf,
> - do_rewind,
> - do_erase,
> - do_eject_media,
> - do_get_device_class,
> - do_display_metrics,
> - do_quit,
> + do_init,
> + do_sync,
> + do_begin_read,
> + do_read,
> + do_return_read_buf,
> + do_get_mark,
> + do_seek_mark,
> + do_next_mark,
> + do_end_read,
> + do_begin_write,
> + do_set_mark,
> + do_get_write_buf,
> + do_write,
> + do_get_align_cnt,
> + do_end_write,
> + do_fsf,
> + do_bsf,
> + do_rewind,
> + do_erase,
> + do_eject_media,
> + do_get_device_class,
> + do_display_metrics,
> + do_quit,
> </pre>
>
> <h4><a name="drive_scsitape">Drive Scsitape</a></h4>
> @@ -1680,10 +1680,10 @@ If xfsdump/xfsrestore is running single-threaded (-Z option)
> or is running on Linux (which is not multi-threaded) then
> records are read/written straight to the tape. If it is running
> multi-threaded then a circular buffer is used as an intermediary
> -between the client and slave threads.
> +between the client and slave threads.
> <p>
> -Initially <i>drive_init1()</i> calls <i>ds_instantiate()</i> which
> -if dump/restore is running multi-threaded,
> +Initially <i>drive_init1()</i> calls <i>ds_instantiate()</i> which
> +if dump/restore is running multi-threaded,
> creates the ring buffer with <i>ring_create</i> which initialises
> the state to RING_STAT_INIT and sets up the slave thread with
> ring_slave_entry.
> @@ -1720,7 +1720,7 @@ Prior to reading, one needs to call <i>do_begin_read()</i>,
> which calls <i>prepare_drive()</i>. <i>prepare_drive()</i> opens
> the tape drive if necessary and gets its status.
> It then works out the tape record size to use
> -(<i>set_best_blk_and_rec_sz</i>) using
> +(<i>set_best_blk_and_rec_sz</i>) using
> current max blksize (mtinfo.maxblksz from ioctl(fd,MTIOCGETBLKINFO,minfo))
> on the scsi tape device in IRIX.
>
> @@ -1737,7 +1737,7 @@ remote tape -> tape_recsz = STAPE_MIN_MAX_BLKSZ = 240 Kb
> On Linux:
> <ul>
> <li>
> -local tape ->
> +local tape ->
> <ul>
> <li>
> tape_recsz = STAPE_MAX_LINUX_RECSZ = 1 Mb<br>
> @@ -1750,7 +1750,7 @@ remote tape -> tape_recsz = STAPE_MIN_MAX_BLKSZ = 240 Kb
> </ul>
> <p>
> If we have a fixed size device, then it tries to read
> -initially at minimum(2Mb, current max blksize)
> +initially at minimum(2Mb, current max blksize)
> but if it reads in a smaller number of bytes than this,
> then it will try again for STAPE_MIN_MAX_BLKSZ = 240 Kb data.
>
> @@ -1766,7 +1766,7 @@ prepare_drive()
> else fixed blksize then
> ok = nread==tape_recsz & !EOD & !EOT & !FileMark
> endif
> - if ok then
> + if ok then
> validate_media_file_hdr()
> else
> could be an error or try again with newsize
> @@ -1802,14 +1802,14 @@ client
> do_read()
> getrec()
> singlethreaded -> read_record() -> Read()
> - else ->
> + else ->
> loop 'til contextp->dc_recp is set to a buffer
> Ring_get() -> ring.c/ring_get()
> remove msg from ready queue
> block on ready queue - qsemP( ringp->r_ready_qsemh )
> msgp = &ringp->r_msgp[ ringp->r_ready_out_ix ];
> cyclic_inc(ringp->r_ready_out_ix)
> - case rm_stat:
> + case rm_stat:
> RING_STAT_INIT, RING_STAT_NOPACK, RING_STAT_IGNORE
> put read msg on active queue
> contextp->dc_msgp->rm_op = RING_OP_READ
> @@ -1818,7 +1818,7 @@ do_read()
> contextp->dc_recp = contextp->dc_msgp->rm_bufp
> ...
> endcase
> - endloop
> + endloop
> </pre>
>
> <h4><a name="librmt">Librmt</a></h4>
> @@ -1835,21 +1835,21 @@ On linux, a librmt library is provided as part of the
> xfsdump distribution.
> The remote functions are used to dump/restore to remote
> tape drives on remote machines. It does this by using
> -rsh or ssh to run rmt(1) on the remote machine.
> +rsh or ssh to run rmt(1) on the remote machine.
> The main caveat, however, comes into play for the <i>rmtioctl</i>
> function. Unfortunately, the values for mt operations and status
> -codes are different on different machines.
> +codes are different on different machines.
> For example, the offline command op
> on IRIX is 6 and on Linux it is 7. On Linux, 6 is rewind and
> -on IRIX 7 is a no-op.
> +on IRIX 7 is a no-op.
> So for the Linux xfsdump, the <i>rmtiocl</i> function has been rewritten
> -to check what the remote OS is (e.g. <i>rsh host uname</i>)
> -and do appropriate mappings of codes.
> +to check what the remote OS is (e.g. <i>rsh host uname</i>)
> +and do appropriate mappings of codes.
> As well as the different mt op codes, the mtget structures
> differ for IRIX and Linux and for Linux 32 bit and Linux 64 bit.
> -The size of the mtget structure is used to determine which
> +The size of the mtget structure is used to determine which
> structure it is and the value of <i>mt_type</i> is used to
> -determine if endian conversion needs to be done.
> +determine if endian conversion needs to be done.
> <p>
>
> <h4><a name="drive_minrmt">Drive Minrmt</a></h4>
> @@ -1863,13 +1863,13 @@ as a parameter. It was designed for talking
> to remote NON-IRIX hosts where the status codes can vary.
> However, as was mentioned in the discussion of librmt on Linux,
> the mt operations vary on foreign hosts as well as the status
> -codes. So this is only a limited solution.
> +codes. So this is only a limited solution.
>
> <h4><a name="drive_simple">Drive Simple</a></h4>
> The simple strategy was designed for dumping to files
> or stdout. It is simpler in that it does <b>NOT</b> have to worry
> about:
> -<ul>
> +<ul>
> <li>the ring buffer
> <li>talking to the scsitape driver with various operations and status
> <li>multiple media files
> @@ -1879,7 +1879,7 @@ about:
> <hr>
> <h3><a name="inventory">Online Inventory</a></h3>
> xfsdump keeps a record of previous xfsdump executions in the online inventory
> -stored in /var/xfsdump/inventory or for Linux, /var/lib/xfsdump/inventory.
> +stored in /var/xfsdump/inventory or for Linux, /var/lib/xfsdump/inventory.
> This inventory is used to determine which previous dump a incremental dump
> should be based on. That is, when doing a level > 0 dump for a filesystem,
> xfsdump will refer to the online inventory to work out when the last dump for
> @@ -1928,7 +1928,7 @@ The files are constructed like so:
> <th>Data structure</th>
> </tr>
> <tr>
> - <td>1</td>
> + <td>1</td>
> <td>
> <pre>
> typedef struct invt_counter {
> @@ -1943,10 +1943,10 @@ typedef struct invt_counter {
> } invt_counter_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> - <td>1 per filesystem</td>
> - <td>
> + <td>1 per filesystem</td>
> + <td>
> <pre>
> typedef struct invt_fstab {
> uuid_t ft_uuid;
> @@ -1956,7 +1956,7 @@ typedef struct invt_fstab {
> } invt_fstab_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> </table>
>
>
> @@ -1968,7 +1968,7 @@ typedef struct invt_fstab {
> <th>Data structure</th>
> </tr>
> <tr>
> - <td>1</td>
> + <td>1</td>
> <td>
> <pre>
> typedef struct invt_counter {
> @@ -1982,10 +1982,10 @@ typedef struct invt_counter {
> } invt_counter_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> - <td>1 per StObj file</td>
> - <td>
> + <td>1 per StObj file</td>
> + <td>
> <pre>
> typedef struct invt_entry {
> invt_timeperiod_t ie_timeperiod;
> @@ -1994,7 +1994,7 @@ typedef struct invt_entry {
> } invt_entry_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> </table>
>
> <h4>StObj</h4>
> @@ -2005,7 +2005,7 @@ typedef struct invt_entry {
> <th>Data structure</th>
> </tr>
> <tr>
> - <td>1</td>
> + <td>1</td>
> <td>
> <pre>
> typedef struct invt_sescounter {
> @@ -2021,11 +2021,11 @@ typedef struct invt_sescounter {
> } invt_sescounter_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> - <td>fixed space for<br>
> + <td>fixed space for<br>
> INVT_STOBJ_MAXSESSIONS (ie. 5)</td>
> - <td>
> + <td>
> <pre>
> typedef struct invt_seshdr {
> off64_t sh_sess_off; /* offset to rest of the sessioninfo */
> @@ -2039,11 +2039,11 @@ typedef struct invt_seshdr {
> } invt_seshdr_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> - <td>fixed space for<br>
> + <td>fixed space for<br>
> INVT_STOBJ_MAXSESSIONS (ie. 5)</td>
> - <td>
> + <td>
> <pre>
> typedef struct invt_session {
> uuid_t s_sesid; /* this session's id: 16 bytes*/
> @@ -2053,14 +2053,14 @@ typedef struct invt_session {
> char s_devpath[INV_STRLEN];/* path to the device */
> u_int s_cur_nstreams;/* number of streams created under
> this session so far */
> - u_int s_max_nstreams;/* number of media streams in
> + u_int s_max_nstreams;/* number of media streams in
> the session */
> char s_padding[16];
> } invt_session_t;</pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> - <td rowspan=2>any number</td>
> + <td rowspan=2>any number</td>
> <td>
> <pre>
> typedef struct invt_stream {
> @@ -2078,7 +2078,7 @@ typedef struct invt_stream {
> } invt_stream_t;
> </pre>
> </td>
> - </tr>
> + </tr>
> <tr>
> <td>
> <pre>
> @@ -2086,7 +2086,7 @@ typedef struct invt_mediafile {
> uuid_t mf_moid; /* media object id */
> char mf_label[INV_STRLEN]; /* media file label */
> invt_breakpt_t mf_startino; /* file that we started out with */
> - invt_breakpt_t mf_endino; /* the dump file we ended this
> + invt_breakpt_t mf_endino; /* the dump file we ended this
> media file with */
> off64_t mf_nextmf; /* links to other mfiles */
> off64_t mf_prevmf;
> @@ -2096,7 +2096,7 @@ typedef struct invt_mediafile {
> char mf_padding[15];
> } invt_mediafile_t;
> </pre>
> - </td>
> + </td>
> </tr>
> </table>
>
> @@ -2123,12 +2123,12 @@ and modify the inventory.
> If -a is NOT used then it looks like nothing special happens
> for files which have dmf state attached to them.
> So if the file uses too many blocks compared to our maxsize param (-z)
> -then it will not get dumped. No inode nor data.
> +then it will not get dumped. No inode nor data.
> The only evidence will be its entry in the inode
> map (which is dumped) which says its the state of a no-change-non-dir and
> the directory entry in the directories dump. The latter will mean
> that an <i>ls</i> in xfsrestore will show the file but it can
> -not be restored.
> +not be restored.
> <p>
> If -a <b>is</b> used and the file has some DMF state then we do some magic.
> However, the magic really only seems to occur for dual-state files
> @@ -2138,7 +2138,7 @@ A file is marked as dual-state/unmigrating by looking at the DMF attribute,
> dmfattrp->state[1]. i.e = DMF_ST_DUALSTATE or DMF_ST_UNMIGRATING
> If this is the case, then we set, dmf_f_ctxtp->candidate = 1.
> If we have such a changed dual-state file then we
> -mark it as changed in the inode-map so it can be dumped.
> +mark it as changed in the inode-map so it can be dumped.
> If it is a dual state file, then its apparent size will be zero, so it
> will go onto the dumping stage.
> <p>
> @@ -2162,7 +2162,7 @@ and add a new DMF attribute for it:
> <br>
> <b>Summary:</b>
> <ul>
> -<li>dual state files (and unmigrating files) dumped with -a,
> +<li>dual state files (and unmigrating files) dumped with -a,
> cause magic to happen:
> <ul>
> <li>if file has changed then it will _always_ be marked
> @@ -2175,7 +2175,7 @@ and add a new DMF attribute for it:
> <li>for all other cases,
> if the file has changed and its blocks cause it to exceed the
> maxsize param (-z) then the file will be marked as NOT-CHANGED
> - in the inode map and so will NOT be dumped at all
> + in the inode map and so will NOT be dumped at all
> </ul>
> <p>
>
> @@ -2196,7 +2196,7 @@ its entries <inode#,gen#,entry-sz,csum,entry-name>
> and extended-attribute header and attributes.
> <p>
> A non-directory file consists of a file header, extent-headers
> -(for each extent), file data and extended-attribute header
> +(for each extent), file data and extended-attribute header
> and attributes. Some types of files don't have extent headers or data.
> <p>
> The xfsdump code says:
> @@ -2217,7 +2217,7 @@ So this accounts for the:
> <li>global header
> <li>inode map
> <li>all the files
> - <li>all the direntory entries
> + <li>all the direntory entries
> ( "+8" presumably to account for average file name length range,
> where 8 chars already included in header; as this structure
> is padded to the next 8 byte boundary, it accounts for names
> @@ -2253,7 +2253,7 @@ It includes for each file:
> <ul>
> <li>any hole hdrs
> <li>alignment hdrs
> - <li>alignment padding
> + <li>alignment padding
> <li>extent headers for data
> <li>actual _data_ of extents
> </ul>
> @@ -2267,7 +2267,7 @@ From code:
> bytecnt += sizeof( extenthdr_t ); /* ext. alignment header */
> bytecnt += ( off64_t )cnt_to_align /* alignment padding */
> bytecnt += sizeof( extenthdr_t ); /* extent header for data */
> - bytecnt += ( off64_t )actualsz; /* actual extent data in file */
> + bytecnt += ( off64_t )actualsz; /* actual extent data in file */
> bytecnt += ( off64_t )reqsz; /* write padding to make up extent size */
> sc_stat_datadone += ( size64_t )bc;
> </pre>
> @@ -2285,7 +2285,7 @@ nor the extent hdr terminator:
> contextp->cc_mfilesz += bytecnt;
> </pre>
> It only adds this data size into the media file size.
> -
> +
> </dl>
> <p>
> <hr>
> @@ -2297,7 +2297,7 @@ It only adds this data size into the media file size.
> <li>What is the difference between a record and a block ?
> <ul><li>I don't think there is a difference.</ul>
> <li>Where are tape_recsz and tape_blksz used ?
> - <ul><li>Tape_recsz is used for the read/write byte cnt but
> + <ul><li>Tape_recsz is used for the read/write byte cnt but
> I don't think tape_blksz is used.</ul>
> <li>What is the persistent inventory used for ?
> </ul>
> diff --git a/po/de.po b/po/de.po
> index 62face8..142f68f 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -446,8 +446,8 @@ msgstr ""
> "zurück, Fehlernummer %d (%s)\n"
>
> #: .././common/drive_minrmt.c:3823
> -msgid "slave"
> -msgstr "Slave"
> +msgid "worker"
> +msgstr "Worker"
I think this ^^ hunk belongs in the next patch.
The rest LGTM,
Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
--D
>
> #: .././common/drive_minrmt.c:3891 .././common/drive_minrmt.c:3899
> msgid "KB"
>
>
