xfs
[Top] [All Lists]

Re: Extended attributes: process vs. kernel context (e.g. HSM)

To: Andreas Gruenbacher <agruen@xxxxxxx>
Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM)
From: Dean Roehrich <roehrich@xxxxxxx>
Date: Fri, 15 Nov 2002 12:50:13 -0600
Cc: Steve Lord <lord@xxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, "Theodore Ts'o" <tytso@xxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxx>, ext2-devel@xxxxxxxxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
>From:  Andreas Gruenbacher <agruen@xxxxxxx>

>> The inode and any thing like ACLs etc is always on disk, and
>> permission to look at the contents can be determined without the
>> contents being present. Once past this point, the data is discovered
>> to be offline and the HSM daemons are responsible for bringing it
>> back on line, they are the only ones who need to manipulate HSM
>> related metadata.
>
>I would define the online/offline flag part of the HSM metadata. Of 
>course that piece of information could be stored as some an inode flag, 
>separate from the rest of the metadata which lives in an extended 
>attribute. Then the kernel only needs to access this flag, and only the 
>user space process cares about the EA.

For XFS it isn't an online/offline flag; it's a bitmask that indicates which
DMAPI events should be triggered for various operations on that file.  This
mask is store in the XFS inode.

Dean


<Prev in Thread] Current Thread [Next in Thread>