hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurtis Heimerl (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1298) adding user info to file
Date Wed, 09 May 2007 21:30:16 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494578
] 

Kurtis Heimerl commented on HADOOP-1298:
----------------------------------------

1-> I don't see why you want to OR things. I don't see any possible use for that, as this
is an object that's going to be returned by the file system. As far as storing as octal/binary,
that's not a terrible way to do it. If I were to do that, I'd need to start at the head and
pass the octal representation around the whole way through. I like the fact that this seperates
the FileStatus from the Permissions, as one is a DFS implementation detail and one is a client
implementation detail. 

2-> ok

3-> ok

4-> ok

5-> How? What does it have to do with file status?

6-> ok

7-> I disagree. As state above, these are two different components of two different systems.
I don't think that a change to the clientside representation of permissions should cause a
change to the DFS representation of permissions. Although they use a very similar mechanism,
the seperation is important. 

8-> Permissions is a structure internal to the INode. DFSFileInfo objects are just a way
to return immutable state to the client. DFSFileInfo will replicate some state as it's sent
over the wire. For instance, it currently contains blockReplication taken from the INode.
Permissions are just another spot of state from the inode, so we cannot combine these in any
meaningful way. They perform seperate functions. 

Again, FileStatus is an object in the client while DFSFileInfo is an object in DFS. I like
this a lot more than permissions and file status sharing code, as perhaps filestatus could
be a template for the various file system implementations to return status updates. However,
this requires more debate in my head. FileStatus would need to be more general, as it will
be the superclass of all possible file system permissions returns. 

9-> We could move the statics to another class that is instantiated on a per name node
basis. I'd prefer it to reside in FSDirectory as that is a more reasonable place to me. 

> adding user info to file
> ------------------------
>
>                 Key: HADOOP-1298
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1298
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: dfs, fs
>            Reporter: Kurtis Heimerl
>         Attachments: hadoop-user-munncha.patch, hadoop-user-munncha.patch, hadoop-user-munncha.patch,
hadoop-user-munncha.patch10, hadoop-user-munncha.patch11, hadoop-user-munncha.patch12, hadoop-user-munncha.patch4,
hadoop-user-munncha.patch5, hadoop-user-munncha.patch6, hadoop-user-munncha.patch7, hadoop-user-munncha.patch8,
hadoop-user-munncha.patch9
>
>
> I'm working on adding a permissions model to hadoop's DFS. The first step is this change,
which associates user info with files. Following this I'll assoicate permissions info, then
block methods based on that user info, then authorization of the user info. 
> So, right now i've implemented adding user info to files. I'm looking for feedback before
I clean this up and make it offical. 
> I wasn't sure what release, i'm working off trunk. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message