Re: xfsdump feature request

[Jeremy Jackson <jerj@xxxxxxxxxxxx>]

Hi Mandy,

Thanks for looking into this.  I see XFS as the Linux filesystem with 
the greatest potential.  I hope contribute ideas that help integrate it 
fully.

See my comments below.

Mandy Kirkconnell wrote:
> Hi Jeremy,
>
> Jeremy Jackson wrote:
-miniroot explanation omitted--

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

--tmpfs solution omitted--
This will do.

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

Pointing to the xfsrestore man page for a possible use would do the 
trick.   Also missing from the xfsrestore man page is how to use these 
inventory files, and how they are/are not merged into the inventory 
database.

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

I have not used Veritas Backup Exec personally.  The idea came out of a 
discussion with an admin that uses Veritas.  We were comparing the 
features of xfsdump and Veritas.

You are correct - the count is used to determine when a tape should be 
replaced.  I'm not sure if it tracks the restores, but as these are 
hopefully infrequent tracking the writes should give a reasonable 
estimate of the tape's life.

I'm thinking about making a separate erase utility that can optionally 
copy the UUID from the tape and create a dummy media file or stream 
terminator after erasing the tape (optional quick erase - just a rewind 
and overwrite).  It could track tape life separate from inventory 
database for now.  Since tapes must be erased before being reused anyhow 
due to the way xfsdump -o works, this seems logical.

That actually reminds me of another issue.  When appending a dump 
session to a tape with other dump sessions, you don't use the -o flag. 
But if the session fills the tape, the new tape inserted must not have 
any xfsdump sessions, or the dump aborts (can't choose overwrite in 
middle of a dump).

"mt erase" takes 3 hours on this Exabyte drive, so I came up with a 
shortcut:

mt rewind ; dd if=/dev/zero of=/dev/tape count=1 bs=245760
(where bs= is the -b size used with xfsdump).

It thinks the tape is a corrupt xfsdump tape or a foreign tape, and 
allows overwrite.

I'm not sure what the recomendation for xfsdump is in this scenario... 
if there is one perhaps it could go in the manpage.

Regards,

Jeremy Jackson