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
|