>From: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
>On Mon, Jul 09, 2001 at 10:05:37AM -0500, James A Goodwin wrote:
>> Does anyone know the extent to which DMAPI information is handled by
>> xfsdump/xfsrestore? There are two things that worry me:
>> 1. Are xfsdump/xfsrestore smart enough to realize when data is not resident
>> on XFS disks? In other words, the data has been migrated by the DMAPI
>> client, and dm_puch_hole() was used to free up the XFS disk resources.
>> When doing a dump, I'd rather have xfsdump note that there is a hole rather
>> than dredging all the migrated data back up through the DMAPI.
>> The xfsdump man page mentions a "-a" option for
>> working with DMF that sounds a lot like an answer to #1, but I'd be
>> surprised if there was any relationship between DMF and DMAPI.
xfsdump has to know how to unpack DMF's extended attributes so it can figure
out if the file is online or offline, and do the intelligent thing when doing
the backup. Other HSM's pack their extended attributes in different ways, and
the XDSM (DMAPI) spec doesn't say the attributes have to be structured any
Our DMAPI--and our HSM--does not yet support multiple managed regions, so
xfsdump just has to figure out if the file, as a whole, is online or offline.
So when you're reading xfsdump/restore code you're not going to find the stuff
that punches holes whereever there's an offline region.
So if you're on Irix and using an HSM other than DMF on an XFS filesystem then
xfsdump is not going to do the right thing.
>I'm not that "au fait" with DMAPI stuff - Dean (roehrich@xxxxxxx)
>would be the one with answers to such questions :)
>the "-a" option is used to dump DMF dual-state and unmigrating
>files as offline (so no data is dumped).
>Looking at the code,
> - its extent data will be dumped as 1 extent with a hole
> (so the data aint dumped)
> - its DMF attributes won't be dumped but a replacement DMF attribute
> (i.e. DMF_ST_OFFLINE) will be dumped in its place
> - the stat buf's bs_devmask will be or'ed with DM_EVENT_READ
>(I don't know if this is enought for all DMAPI users or just DMF ?)
It's not enough--other HSM's won't use the same DMF_ST_* values and they won't
use the same format we have defined in XFSattrvalue1_t. The comments and
symbol names early in dump/hsmapi.c make it clear this stuff is not expected
to satisfy any other HSM.
>> 2. What do xfsdump/xfsrestore do with DM attributes, regions, and event
>> lists? Are they stored, ignored, or something else?
>I presumed all the DMAPI event stuff and other related data is
>in extended attributes. And all the extended attributes are
>dumped out (unless the -A option is used).
A couple of masks are in the inode: io_dmevmask/di_dmevmask and
io_dmstate/di_dmstate. Any HSM using our DMAPI will rely on dmevmask and will
build with /usr/include/xfs/dmapi.h to get the mask bits.
The dmstate field is not used and the purpose for its presence in our inode,
and any possible meaning it may have, is a piece of lost history. It's not
part of the DMAPI spec. However, it's a couple of bits we own in the inode
and we're reserving them. I noticed that on the Linux side xfsdump sets it to
zero--the Irix xfsdump doesn't touch it. The confusion is not surprising, I
The rest of the information, as far as offline/online, region info...is in the
extended attribute and so would be HSM-specific. This attribute is also given
an HSM-specific name.
>Hmmmm....xfsrestore takes the -D option to restore DMAPI event
>settings. If F_FSSETDM macro is set then it uses fcntl(F_FSSETDM).
>All this code is #ifdef'ed out by the macro F_FSSETDM.
>This doesn't seem to be turned on in IRIX or Linux.
>Dean, is it not necessary to call fcntl(F_FSSETDM) ?
It is turned on in Irix. The makefile defines BANYAN unconditionally (found
only in the Irix-side code), and F_FSSETDM is defined in <sys/fcntl.h>--so
that code is enabled on Irix. The stuff inside the #ifdef F_FSSETDM will have
to be ported to use the XFS_IOC_FSSETDM ioctl on Linux.
(I'm copying this to the openxdsm-devel mailing list...just in case anyone
there is still alive.)