Re: xfsdump feature request

[Mandy Kirkconnell <alkirkco@xxxxxxx>]

Hi Jeremy,

Jeremy Jackson wrote:
> 1) xfsdump -J ... it is required when /var is mounted read-only.  This
> inhibits writing the dump session to /var/lib/xfsdump/inventory, as well as
> writing the dump session to a tape file.  Yet when booted from cd/network
> and root is read-only, it is often desirable to make a dump while doing
> system repairs (xfs_repair needs to boot from somewhere else to run even).
> Also related is the "miniroot" environment in the xfsdump man page... this
> could use some more explanation.

miniroot is an IRIX installation tool used when fundamental IRIX 
services, such as filesystem management, are unavailable.  It's used to 
transfer installation tools from the source distribution to the target 
system using PROM (programmable read-only memory) and the swap partition 
of the disk.  The Linux xfsdump man page should NOT be making any 
references to miniroot.  This must have been overlooked when porting the 
xfsdump man page from IRIX to Linux. It will be fixed in an upcoming 
release.  Thanks!

> It would be nice if -J or some other option would allow the user to bypass
> the update of /var/lib/xfsdump/inventory, but still write the session
> inventory to a tape file, since xfsrestore can later be used to merge (or
> inspect?) it when listing/restore a session.  (related to #2)

This would be a nice-to-have feature but I'm not sure how high of a 
priority this is right now.  I'll open an internal RFE (requested 
feature enhancement) but I can't guarantee that we'll be able to get to 
it right away.

Would you settle for a workaround in the meantime?

Depending on how much memory you have and how big your inventory files 
are, you could use tmpfs to mount a temporary writeable directory on 
/var/lib/xfsdump/inventory.  This will trick xfsdump so it doesn't force 
you to use the -J option (since /var/lib/xfsdump/inventory will appear 
writeable).  The inventory will then be written to the tmpfs swap space 
as well as to the tape.  When the dump has completed you can unmount 
tmpfs, discarding any inventory file(s) written to memory. tmpfs grows 
dynamically so you may want to set a size limit on it.

  # mount -t tmpfs tmpfs /dev/shm
  # mount -w -t tmpfs tmpfs /var/lib/xfsdump/inventory

  # Or, add these lines to /etc/fstab:
  tmpfs   /dev/shm                   tmpfs  defaults             0 0
  tmpfs   /var/lib/xfsdump/inventory tmpfs  size=750M,mode=2777  0 0

See the tmpfs documentation in the kernel source tree for more info on 
tmpfs:  "linux/Documentation/filesystems/tmpfs.txt".

> 2)  The man page for xfsdump states that the inventory written to tape is
> currently not used, however I was able to merge it into
> /var/lib/xfsdump/inventory when using xfsrestore to list a session on tape.
> It would be nice if the man pages stated exactly when and how the inventory
> file on the tape is used/not used.

I think when the man page says the inventory file on the tape isn't 
used, it means that xfsdump neither looks at it nor depends upon it. 
xfsdump only looks at inventory files in /var/lib/xfsdump/inventory when 
searching for a specific dump.  The inventory file that gets added to 
the tape at the end of each dump session is for the user's benefit only, 
in order to query the dump sessions on a given tape.

Does this make sense?  Perhaps a better explanation in the xfsdump man 
page is needed.

> 3) This has been mentioned before on the list... What is the difference
> between "mt erase" and "xfsdump -o" and "xfsdump -E".

   mt erase     Erases tape from CURRENT position to end of tape (EOT)
   xfsdump -o   Overwrites tape without checking contents
   xfsdump -E   Pre-Erases ENTIRE tape from BOT to EOT

> Is there a way to erase a tape but keep it's media object UUID.

Unforchunately, no.  All three of the options above cause a new media 
objec UUID to be created when the next (first) dump begins.

> It would be ideal to allow this, and prune the inventory of that
>  media object's UUID automatically. If this is possible, then adding
> a counter to how many times that media object has been used would
> give it all the features of Veritas.  Would be nice.

You can use the 'mobjid=' option with -I to prune out the inventory of a 
specific media object's UUID, but (as you mentioned) the media id is not 
constant for a given tape.  I agree, it would be really nice if xfsdump 
could associate a constant media id for each tape, where the id remained 
constant accross erases, overwrites, etc..  I'll open an RFE for this as 
well.

I'm not all that familiar with the Veritas products, maybe you can help 
me out here.  Would the purpose of a counter be to keep track of the 
life span of each tape?  Would it include the number of dumps (writes) 
AND the number of restores (reads), or just the dumps?

Thanks,
Mandy

--
Mandy Kirkconnell
SGI, Storage Software Engineer
alkirkco@xxxxxxx