[Lustre-devel] Re-direction inodes
Peter.Braam at Sun.COM
Tue Jun 3 18:17:27 PDT 2008
The last sentence in your message is correct. But it seems that Nikita and
I have managed to design it "out of the way" - I'll write it up and share it
On 6/3/08 2:09 AM, "Andreas Dilger" <adilger at sun.com> wrote:
> On Jun 02, 2008 08:59 +0900, Peter J. Braam wrote:
>> I have a need in doing an architecture for a customer of a Lustre client
>> feature to have different data/page caches associated with an inode,
>> depending on the user that accesses it. So when a file is read, user A
>> will read different data from user B (assume the same for writes, but I
>> think this is a read-only feature).
> Initially when I read this, I thought you were only trying to keep the
> client-side cache separate, which could be done by adding the UID into
> the inode lookup function for ll_test_inode() and treating these files
> separately in the client-side cache. That would be useful to avoid e.g.
> user A reading "securefile" into memory, and user B being able to access
> it from cache due to client-local access permissions allowing it.
>> I remember that in the Coda file system we could easily re-direct I/O to
>> another inode using almost standard features in the VFS/page caches. Is
>> this still the case? Would this work for the purpose I describe above?
> On later reading, it seems you want to have completely independent
> file contents for each user, but they share the same pathname. In some
> filesystems it is possible to encode part of the pathname somewhat like:
> but I think you are proposing a completely transparent mapping of content:
> alice> cat /etc/passwd
> bob> cat /etc/passwd
> Cheers, Andreas
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
More information about the lustre-devel