|To:||Mandy Kirkconnell <alkirkco@xxxxxxx>|
|Subject:||Re: xfsdump feature request|
|From:||Jeremy Jackson <jerj@xxxxxxxxxxxx>|
|Date:||Tue, 25 Nov 2003 14:28:13 -0500|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3|
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:
-miniroot explanation omitted--
It would be nice if -J or some other option would allow the user to bypass
> 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.
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.
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: XFS RAID only writing half the time, Dirk Hufnagel|
|Next by Date:||Re: xfsdump fails to overwrite stream terminator - dumps lost, Jeremy Jackson|
|Previous by Thread:||Re: xfsdump feature request, Mandy Kirkconnell|
|Next by Thread:||Re: xfsdump feature request, Mandy Kirkconnell|
|Indexes:||[Date] [Thread] [Top] [All Lists]|