From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F20DC00140 for ; Wed, 10 Aug 2022 15:09:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229867AbiHJPJh (ORCPT ); Wed, 10 Aug 2022 11:09:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232973AbiHJPJS (ORCPT ); Wed, 10 Aug 2022 11:09:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1888D760F8 for ; Wed, 10 Aug 2022 08:09:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8317660DCC for ; Wed, 10 Aug 2022 15:09:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D214EC433D7; Wed, 10 Aug 2022 15:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660144153; bh=mIEqwNTlD4MahxzWLKogJGVEIejRmGozu3DUezjdK/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uwv54GbmPg5Y7Tx5E7ZyY7Njn9uP0tcVj/JkJ87MdraLPOk6khmD9YGSI/P0S32Ft t5scMI2hr17qNAcM7bmWhLXgLi+u5xUVmKhEMstOAXn98tJrRcRAHpPXFtmzgD3/Ou pftgRe0aldKP+fPljdDb6bPvP9Crp0MwAa+0eW6/Iiwbyug31Nyar7L/lqXXOXvi9e 3Fn/KM9by2iwVber0Yfp93XC1RxpK4GgoisrSdpv1DFERr99AVkZzQ1Gb8ymkjqyZP s8o6An4SyPF43rX39C1qbsLhgONDv351wXWL5rVxdvz819vT9Ca4Zkaj2FCiH6V0l4 mCWm/jfHLjs4g== Date: Wed, 10 Aug 2022 08:09:12 -0700 From: "Darrick J. Wong" To: Carlos Maiolino Cc: linux-xfs@vger.kernel.org Subject: Re: [PATCH 1/2] Remove trailing white spaces from xfsdump.html Message-ID: References: <166012867440.10085.15666482309699207253.stgit@orion> <166012880601.10085.14032914718801896551.stgit@orion> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <166012880601.10085.14032914718801896551.stgit@orion> Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org 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 > --- > 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 @@ >
    >
  • The main function of xfsdump > >
  • Dumping to Tape >
      > @@ -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. > >
      >

      What's in a dump

      > @@ -95,7 +95,7 @@ or stdout. The dump includes all the filesystem objects of: >
        >
      • directories (S_IFDIR) >
      • regular files (S_IFREG) > -
      • sockets (S_IFSOCK) > +
      • sockets (S_IFSOCK) >
      • symlinks (S_IFLNK) >
      • character special files (S_IFCHR) >
      • block special files (S_IFBLK) > @@ -106,7 +106,7 @@ xfsdump inventory is located. > Other data which is stored: >
          >
        • file attributes (stored in stat data) of owner, group, permissions, > -and date stamps > +and date stamps >
        • any extended attributes associated with these file objects >
        • 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) > > >

          > Note that the strategy id 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. > >

          > - > + > >

          Inode Map

          > > @@ -227,8 +227,8 @@ then the file can be dumped in multiple records or extent groups. >

          Format on Tape

          > 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: > 
          >  rec_hdr
> @@ -246,28 +246,28 @@ dump uuid
>  pad to 512 bytes
>
          >

          > -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. >

          > 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 do_get_write_buf, > -copies over the data one wants stored and then > +copies over the data one wants stored and then > calls do_write_buf, until the entire data buffer > has been copied over. > > -

          > +
          > >

          Run Time Structure

          > > -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. >

          > 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 > content_stream_dump and content_stream_restore. > >

          > @@ -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) >
        • phase 3: 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. >
        • phase 4: 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. >
        • phase 5: 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. >
        > > @@ -428,13 +428,13 @@ create inode-ranges for multi-stream dumps if pertinent. >
      • end the media file >
      • update online inventory >
      > -
    • if multiple-media dump (i.e. tape dump and not file dump) then > +
    • if multiple-media dump (i.e. tape dump and not file dump) then >
        >
      • dump the session inventory to a media file >
      • dump the terminator to a media file >
      >
    > - > + >
    > >
    The main function of xfsdump
    > @@ -442,7 +442,7 @@ create inode-ranges for multi-stream dumps if pertinent. > 
    >  * drive_init1 - 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.
>  
> -* create global header 
> +* create global header
>    - 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
>  
> -  - phase1: parsing subtree selections (specified by -s options) 
> -    INPUT: 
> +  - phase1: parsing subtree selections (specified by -s options)
> +    INPUT:
>  	- sub directory entries (from -s)
>      FLOW:
> -	- 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
> -  
> +
>    - phase2: creating inode map (initial dump list)
> -    INPUT: 
> +    INPUT:
>        - bulkstat records on all the inodes in the file system
>      FLOW:
>        - 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
>      OUTPUT:
> -	- 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)
> -    - phase3:  pruning inode map (pruning unneeded subtrees) 
> +    - phase3:  pruning inode map (pruning unneeded subtrees)
>  	INPUT:
>  	    - 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.)
>  
>  	  * dump_file_reg (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.
>  * dump_file_reg (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.
>  
    
>  
>  
    Splitting a Regular File
    
> -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.
>  
    Splitting a dump over multiple streams (Phase 5)
    
>  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 bulkstat in the function 
> +determine how much data we should allocate for a stream.
> +The inodes are processed in order from bulkstat in the function
>  cb_startpt. 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:
>  
    
>  
    Hold
>  
    Include this file in the current stream.
> -
    Bump 
> +
    Bump
>  
    Start a new stream beginning with this file.
>  
    Split
>  
    Split this file across 2 streams in different extent groups.
> @@ -850,8 +850,8 @@ Initialize the mmap files of:
>    
  •  search for directory dump
>    
  •  calls dirattr_init if necessary
>    
  •  calls namreg_init if necessary
> -  
  •  initialize the directory tree (tree_init) 
> -  
  •  read the dirents into the tree 
> +  
  •  initialize the directory tree (tree_init)
> +  
  •  read the dirents into the tree
>         (applydirdump)
>
> > @@ -866,17 +866,17 @@ Initialize the mmap files of: > >
  • all threads can process each media file of their dumps for > restoring the non-directory files > -
      > -
    • loop over each media file > +
        > +
      • loop over each media file >
          >
        • read in file header > -
        • call applynondirdump for file hdr > -
            > -
          • restore extended attributes for file > - (if it is last extent group of file) > +
          • call applynondirdump for file hdr > +
              > +
            • restore extended attributes for file > + (if it is last extent group of file) >
            • restore file >
                > -
              • loop thru all hardlink paths from tree for inode > +
              • loop thru all hardlink paths from tree for inode > (tree_cb_links) and call restore_file_cb >
                  >
                • if a hard link then link(path1, path2) > @@ -890,11 +890,11 @@ Initialize the mmap files of: >
                • set DMAPI fields if necessary >
                • loop processing the extent headers >
                    > -
                  • if type LAST then exit loop > +
                  • if type LAST then exit loop >
                  • if type ALIGN then eat up the padding >
                  • if type HOLE then ignore > -
                  • if type DATA then copy the data into > - the file for the extent; > +
                  • if type DATA then copy the data into > + the file for the extent; > seeking to extent start if necessary >
                  >
                • register the extent group in the partial registry > @@ -917,9 +917,9 @@ Initialize the mmap files of: >
                • if corrupt then go to next mark >
                • else exit loop >
                > -
              > +
            >
          > -
        > +
      > >
    • one stream does while others wait: >
        > @@ -937,7 +937,7 @@ Initialize the mmap files of: > content_init in a bit more detail(xfsrestore version) >
          >
        • 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. >
        • 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: >

          Persistent Inventory and State File

          > > 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 > $dstdir/xfsrestorehousekeepingdir/state. > -The state file (struct pers from content.c) contains > +The state file (struct pers from content.c) contains > a header of: >
            >
          • command line arguments from 1st session, >
          • partial registry data structure for use with multiple streams > - and extended attributes, > + and extended attributes, >
          • various session state such as > dumpid, dump label, number of inodes restored so far, etc. >
          > @@ -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. >

          > -The tree is an mmap'ed file called > +The tree is an mmap'ed file called > $dstdir/xfsrestorehousekeepingdir/tree. > 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 n_hashh 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. >

          > @@ -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). > > >

          Window Abstraction
          > -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 win_map() to map in a chunk of 8192 nodes > @@ -1185,8 +1185,8 @@ for the node-freelist. > Consider the win_map(offset, return_memptr) function: > 
          >  One is asking for an offset within a segment.
> -It looks up its bag for the segment (given the offset), and 
> -if it's already mapped then 
> +It looks up its bag 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 bag.
>  A bag is just a doubly linked searchable list where
> -the elements are allocated using calloc(). 
> +the elements are allocated using calloc().
>  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.
>  
          >  
>  BAG:  |--------|     |--------|     |--------|     |--------|     |-------|
> @@ -1239,7 +1239,7 @@ win-freelist:   | oldest |               | 2nd    |
>  
          
>  Call Chain
          
>  
> -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.
>  
          
>  
          > @@ -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:
>  
>  applydirdump()
>    ...
> -  inomap_restore_pers() - read ino map 
> +  inomap_restore_pers() - read ino map
>    read directories and their entries
>      loop 'til null hdr
>         dirh = tree_begindir(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
>  restoredir/xfsrestorehousekeepingdir/tree should not be deleted
>  between cumulative restores (as we need to keep using it).
>  
          
> @@ -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 NF_REFED.
>  
          
>  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 NF_REFED) 
> +xfsrestore does an extra pass in the tree preprocessing
> +which traverses the tree looking for non-referenced (not NF_REFED)
>  nodes so that if they exist in the FS (i.e. are NF_REAL) 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 (treepost):
>     1. noref_elim_recurse
>     
            
>     
          • remove deleted dirs
> -   
          • rename moved dirs to orphanage	
> +   
          • rename moved dirs to orphanage
>     
          • remove extra deleted hard links
>     
          • rename moved non-dirs to orphanage
>     
          
> @@ -1443,7 +1443,7 @@ cumulative restoral, it does a 4 step postprocessing (treepost):
>     
        • create a link on rename error (don't understand this one)
>
        > > - > + > >

        > Step 1 was changed so that files which are deleted and not moved > @@ -1459,13 +1459,13 @@ The new step is: > 1. noref_elim_recurse >

          >
        • remove deleted dirs > -
        • rename moved dirs to orphanage > +
        • rename moved dirs to orphanage >
        • remove extra deleted hard links >
        • rename moved non-dirs to orphanage >
        • remove deleted non-dirs which aren't part of a rename >
        > > - > + >

        > 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. >

        >

        Partial Registry

        > > -The partial registry is a data structure used in xfsrestore > -for ensuring that files which have been split into multiple extent groups, > +The partial registry is a data structure used in xfsrestore > +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. >

        > 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). >

        > A bug was discovered in this area of code, for DMF offline files > which have an associated file size but no data blocks allocated and > @@ -1550,7 +1550,7 @@ restore data are now special cased. > >

        Drive Strategies

        > 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: >
          >
        • stat fails > -
        • it is not a character device > -
        • its real path does not contain "/nst", "/st" nor "/mt". > +
        • it is not a character device > +
        • its real path does not contain "/nst", "/st" nor "/mt". >
        > > > @@ -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: > 
        > -        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,
>
        > >

        Drive Scsitape

        > @@ -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. >

        > -Initially drive_init1() calls ds_instantiate() which > -if dump/restore is running multi-threaded, > +Initially drive_init1() calls ds_instantiate() which > +if dump/restore is running multi-threaded, > creates the ring buffer with ring_create 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 do_begin_read(), > which calls prepare_drive(). prepare_drive() opens > the tape drive if necessary and gets its status. > It then works out the tape record size to use > -(set_best_blk_and_rec_sz) using > +(set_best_blk_and_rec_sz) 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: >

          >
        • > -local tape -> > +local tape -> >
            >
          • > tape_recsz = STAPE_MAX_LINUX_RECSZ = 1 Mb
            > @@ -1750,7 +1750,7 @@ remote tape -> tape_recsz = STAPE_MIN_MAX_BLKSZ = 240 Kb >
          >

          > 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 > > >

          Librmt

          > @@ -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 rmtioctl > 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 rmtiocl function has been rewritten > -to check what the remote OS is (e.g. rsh host uname) > -and do appropriate mappings of codes. > +to check what the remote OS is (e.g. rsh host uname) > +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 mt_type is used to > -determine if endian conversion needs to be done. > +determine if endian conversion needs to be done. >

          > >

          Drive Minrmt

          > @@ -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. > >

          Drive Simple

          > The simple strategy was designed for dumping to files > or stdout. It is simpler in that it does NOT have to worry > about: > -
            > +
              >
            • the ring buffer >
            • talking to the scsitape driver with various operations and status >
            • multiple media files > @@ -1879,7 +1879,7 @@ about: >
              >

              Online Inventory

              > 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: > Data structure > > > - 1 > + 1 > > 
              >  typedef struct invt_counter {
> @@ -1943,10 +1943,10 @@ typedef struct invt_counter {
>  } invt_counter_t;
>
              > > - > + > > - 1 per filesystem > - > + 1 per filesystem > + > 
              >  typedef struct invt_fstab {
>      uuid_t  ft_uuid;
> @@ -1956,7 +1956,7 @@ typedef struct invt_fstab {
>  } invt_fstab_t;
>
              > > - > + > > > > @@ -1968,7 +1968,7 @@ typedef struct invt_fstab { > Data structure > > > - 1 > + 1 > > 
              >  typedef struct invt_counter {
> @@ -1982,10 +1982,10 @@ typedef struct invt_counter {
>  } invt_counter_t;
>
              > > - > + > > - 1 per StObj file > - > + 1 per StObj file > + > 
              >  typedef struct invt_entry {
>      invt_timeperiod_t ie_timeperiod;
> @@ -1994,7 +1994,7 @@ typedef struct invt_entry {
>  } invt_entry_t;
>
              > > - > + > > >

              StObj

              > @@ -2005,7 +2005,7 @@ typedef struct invt_entry { > Data structure > > > - 1 > + 1 > > 
              >  typedef struct invt_sescounter {
> @@ -2021,11 +2021,11 @@ typedef struct invt_sescounter {
>  } invt_sescounter_t;
>
              > > - > + > > - fixed space for
              > + fixed space for
              > INVT_STOBJ_MAXSESSIONS (ie. 5) > - > + > 
              >  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;
>
              > > - > + > > - fixed space for
              > + fixed space for
              > INVT_STOBJ_MAXSESSIONS (ie. 5) > - > + > 
              >  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;
              > > - > + > > - any number > + any number > > 
              >  typedef struct invt_stream {
> @@ -2078,7 +2078,7 @@ typedef struct invt_stream {
>  } invt_stream_t;
>
              > > - > + > > > 
              > @@ -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;
>
              > - > + > > > > @@ -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 ls in xfsrestore will show the file but it can > -not be restored. > +not be restored. >

              > If -a is 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. >

              > @@ -2162,7 +2162,7 @@ and add a new DMF attribute for it: >
              > Summary: >

                > -
              • dual state files (and unmigrating files) dumped with -a, > +
              • dual state files (and unmigrating files) dumped with -a, > cause magic to happen: >
                  >
                • if file has changed then it will _always_ be marked > @@ -2175,7 +2175,7 @@ and add a new DMF attribute for it: >
                • 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 >
                >

                > > @@ -2196,7 +2196,7 @@ its entries > and extended-attribute header and attributes. >

                > 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. >

                > The xfsdump code says: > @@ -2217,7 +2217,7 @@ So this accounts for the: >

              • global header >
              • inode map >
              • all the files > -
              • all the direntory entries > +
              • 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: >
                  >
                • any hole hdrs >
                • alignment hdrs > -
                • alignment padding > +
                • alignment padding >
                • extent headers for data >
                • actual _data_ of extents >
                > @@ -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; > > @@ -2285,7 +2285,7 @@ nor the extent hdr terminator: > contextp->cc_mfilesz += bytecnt; > > It only adds this data size into the media file size. > - > + > >

                >

                > @@ -2297,7 +2297,7 @@ It only adds this data size into the media file size. >
              • What is the difference between a record and a block ? >
                • I don't think there is a difference.
                >
              • Where are tape_recsz and tape_blksz used ? > -
                • Tape_recsz is used for the read/write byte cnt but > +
                  • Tape_recsz is used for the read/write byte cnt but > I don't think tape_blksz is used.
                  >
                • What is the persistent inventory used for ? >
                > 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 --D > > #: .././common/drive_minrmt.c:3891 .././common/drive_minrmt.c:3899 > msgid "KB" > >