On Fri, Feb 06, 2004 at 01:42:50PM -0600, James A Goodwin wrote:
I think Deans away for a few days, let me try to answer...
(and get overruled by Dean when he returns ;)
> We have a problem when managing an XFS filesystem using the DMAPI. When we
> copy data from an XFS file to our archive, we cover the file with a DMAPI
> region to inform us of read, write, and truncate events. However, if the
> filesystem is full, we cannot establish this region, and we don't have a
> good way to recover.
> To fix the problem, we plan to preallocate a DM region to each file when it
> is created. This region would not be set to generate any I/O events but
> would serve only to preallocate storage. We could later modify the region
> to generate I/O events. If we couldn't create the region due to space
> constraints, we could just abort the file create.
> I have two questions. First, will this approach work?
Seems like a valid approach to me.
> Second, will the
> pre-allocated region also preallocate space that could be used by DM
No - preallocated space is for file data only.
> I'm guessing that it will allocate one block, stick the region
> in there, and have lots of extra space for other extended attributes (i.e.,
> DM attributes). I'm hoping that it will be enough to ensure that I can
> create, modify, and remove some number of DM attributes without having to
> worry about space shortages, but I have no idea how much space I'll have to
> play with.
I believe SGIs HSM uses the XFS RESBLKS interface to reserve a set
amount of filesystem space, which is only available when allocating
extended attribute space for the root namespace (where the DMAPI