On Friday 15 November 2002 18:18, Steve Lord wrote:
> On Fri, 2002-11-15 at 11:07, Stephen C. Tweedie wrote:
> > Hi,
> >
> > On Mon, Nov 11, 2002 at 04:05:24PM -0500, Theodore Ts'o wrote:
> > I'd have thought that the likely model for an HSM system is that
> > the requesting user process would find the inode marked
> > "not-in-core", and would pass the "please make this inode resident"
> > request out to a separate process for completion. Only that
> > external process would require access to the HSM metadata, so it's
> > not immediately obvious why the initial caller process absolutely
> > has to have access to the HSM metadata.
>
> That's the way our HSM works ;-).
>
> 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.
> The user's thread does need to be able to work out that it is offline.
Agreed.
--Andreas.
|