Yeah, the metadata stored was dynamic, the interface exposed to the client have methods to add additional metadata.
On Tue, May 29, 2012 at 2:50 PM, Petru Dimulescu <petru.dimule...@gmail.com> wrote: > Was the metadata dynamic (map-like)? It looks like your modification > are pretty useful, despite the fact that some of the comments on > HDFS-2006 seem to wonder why on earth extended attributes can be used > for. > > On Tue, May 29, 2012 at 5:09 AM, Chandrasekar <chandruseka...@gmail.com> > wrote: >> Hi, >> I did something similar to this a few months back. There are a >> number of things that you need to change in the name node to >> accommodate this. You can either provide a special type of INode that >> extends the existing INodeFile or INodeDirectory or save additional >> meta data as a part of default inodes created for a file or a >> directory. Then you need to provide additional methods to the >> interface exposed to the client by the name node. These methods will >> be used to access the metadata. You should make sure that the >> additional metadata is persisted along with other file metadata. This >> can be done by saving the metadata as a part of the fsimage. Then the >> metadata will be loaded back to the name node when the system >> restarts. >> >> On Tue, May 29, 2012 at 12:27 AM, Petru Dimulescu >> <petru.dimule...@gmail.com> wrote: >>> Hello, >>> >>> If I understand correctly extended attributes are not supported : >>> https://issues.apache.org/jira/browse/HDFS-2006. >>> >>> How would you store small amounts of metadata ("extended attributes") per >>> HDFS file/directory? Anybody has any experience? >>> >>> thanks, >>> Petru
