>From: Nathan Scott <nathans@xxxxxxx>
>On Fri, Feb 06, 2004 at 01:42:50PM -0600, James A Goodwin wrote:
>> Dean,
>
>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.
You need enough space for an XFS transaction. You're not solving anything by
having regions preallocated.
>> 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
>attributes reside).
Yes. Mentioned briefly in the xfs(5) manpage.
Dunno if this works, but here's how it might be done...
xfs_fsop_resblks_t counts;
fd = open(device, ...);
counts.resblks = 100; /* experiment with it */
ioctl(fd, XFS_IOC_SET_RESBLKS, &counts);
I believe you have to do that everytime you mount the filesystem.
Dean
|