On Fri, Nov 15, 2002 at 05:07:30PM +0000, Stephen C. Tweedie 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.
Sure, and if that external process will either have root (or
CAP_SYS_ADMIN) privileges, then we don't need to do anything special.
However, we might need to do something special is if there is a desire
to examine the HSM metadata in kernel space rather than in user space.
After all, the initial interception where the kernel notices that the
inode isn't resident would likely happen in the kernel, since the idea
is for HSM to be transparent to user processes. So the kernel logic
when opening a file might very well be:
1) Is the the size of the inode zero? (If not, perform a normal open.)
2) The inode is zero; check to see if there is HSM metadata present.
(If not, perform a normal open; the user just opened a
zero-legnth inode. Ho hum.)
3) If HSM metadata is present, then this is a non-resident inode.
Call out to a daemon process to make the inode resident.
In this design, the check to see whether or not HSM metadata is
present or not needs to happen as a privileged call. So it may very
well be useful to be able to pass a flag to get_xattr to indicating
that privileged access to the trusted.* space should be allowed, since
the it is being done for official kernel business.
- Ted
|