>From: John Groves <John@xxxxxxxxxx>
>I have a DM application that uses XFS and dmapi. I need a way to keep
>xfsdump from triggering a data fault on files that have holes punched in
>them. I see that xfsdump has code that knows about DMF attributes, and
>it will avoid triggering DMF data faults if run with the "-a" option. I
>am (not surprisingly) not using an attributes strategy identical to
>DMF's, so this doesn't work for my app.
>Before I tunnel through the whole implementation of xfsdump, I'm hoping
>the dmapi/xfsdump developers could make suggestions as to the best
>approach for getting "-a" behavior with my app. Without going overboard
>to "spoof" DMF behavior, is there a way of doing it without modifying
>xfsdump? If I do need to patch xfsdump, suggestions appreciated as to
>the best approach.
The only way to know the state of the file is to decode the extended attribute
that DMF put on the file. If you're not DMF, then the value of that attribute
is just a stream of bits. xfsdump knows just enough about that attribute so
it can find the relevant bits and make a valid decision about the file.
I presume you are using an extended attribute, applied via dm_set_dmattr? The
easy way out (for us) is to rearrange your attribute so you have relevant bits
that end up where xfsdump is already looking :) Otherwise xfsdump would have
to be modified--at that point maybe it's best to rearrange some things to
allow this to be pluggable.