Hi Nikita - 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). 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? Thanks. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-devel/attachments/20080602/d39b9203/attachment.html
Peter Braam writes: > Hi Nikita - > > 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). > > 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? I am not sure how this can be done with the VFS mechanisms. Alex pointed out that some kind of stacked file system similar to smfs can be used for this purpose. > > Thanks. > > Peter Nikita.
On 6/2/08 8:11 PM, "Nikita Danilov" <Nikita.Danilov at Sun.COM> wrote:> Peter Braam writes: >> Hi Nikita - >> >> 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). >> >> 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? > > I am not sure how this can be done with the VFS mechanisms. Alex pointed > out that some kind of stacked file system similar to smfs can be used > for this purpose.Thanks for replying so quickly. After I read your reply I began to realize that what Coda does is too static to solve this problem. I''m going to schedule some phone time with you to discuss this further - because the customer I am talking to needs something and there are two approaches, one is smfs the other is to re-do the pre-processing of the files on the client when there are multiple different user views (neither is all that nice). Peter> >> >> Thanks. >> >> Peter > > Nikita.
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: /home///$UID///file but I think you are proposing a completely transparent mapping of content: alice> cat /etc/passwd alice:x:1000:1000:Alice:/home/alice:/bin/bash bob> cat /etc/passwd bob:x:1001:1001:Bob:/home/bob:/bin/bash correct? Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
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 with you. Peter 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: > > /home///$UID///file > > but I think you are proposing a completely transparent mapping of content: > > alice> cat /etc/passwd > alice:x:1000:1000:Alice:/home/alice:/bin/bash > > bob> cat /etc/passwd > bob:x:1001:1001:Bob:/home/bob:/bin/bash > > correct? > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel
----- "Andreas Dilger" <adilger at sun.com> wrote:> filesystems it is possible to encode part of the pathname somewhat > like: > > /home///$UID///file > > but I think you are proposing a completely transparent mapping of > content: > > alice> cat /etc/passwd > alice:x:1000:1000:Alice:/home/alice:/bin/bash > > bob> cat /etc/passwd > bob:x:1001:1001:Bob:/home/bob:/bin/bashI *think* autofs5 allows for $UID/$GID in mount maps to provide different mountpoints - but that only gives you a whole unique tree not individual files. Depending on the number of files you wish to be unique for each user you could perhaps use a symlink for the file which then points to an autofs5 map with a $UID in it. You may need to use --bind mounts if it points to a LustreFS. Daire
I wrote something while at NERSC called CHOS that did something along these lines but on a per process tree basis. This allowed me to use a common mount tree but then redirect certain paths based on the PID. The way I tackled it was with a symlink that existed in a /proc directory. The symlink would resolve to different values depending on the PID that was asking. Children processes would inherit the same value unless they explicitly changed it. I don''t know if this is of any use, but I just thought I would mention it. --Shane -----Original Message----- From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Andreas Dilger Sent: Monday, June 02, 2008 1:10 PM To: Peter Braam Cc: Nikita Danilov; lustre-devel at lists.lustre.org Subject: Re: [Lustre-devel] Re-direction inodes On Jun 02, 2008 08:59 +0900, Peter J. Braam wrote:> I have a need in doing an architecture for a customer of a Lustreclient> 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, butI> 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/Oto> another inode using almost standard features in the VFS/page caches.Is> this still the case? Would this work for the purpose I describeabove? 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: /home///$UID///file but I think you are proposing a completely transparent mapping of content: alice> cat /etc/passwd alice:x:1000:1000:Alice:/home/alice:/bin/bash bob> cat /etc/passwd bob:x:1001:1001:Bob:/home/bob:/bin/bash correct? Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. _______________________________________________ Lustre-devel mailing list Lustre-devel at lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-devel