Emc IP Holding Company LLC

Microsoft Technology Licensing, LLC

Steven Hubbell

Tanuj Khurana

Matthias Adam Leibmann

Frank Byrum

Jeffrey B Kay

Trevor William Freeman

Ronald Steinke

Jonathan Mark Walton

Ryan Matthew Peterson

Ladislau Conceicao

Raeanne Marks

Claudio Fahey

Jacob Low

David Tucker

Karthik Palaiappan

Implementations are provided herein for using inode revision numbers associated with a modified LIN and a set of Parent LINs to causally order transactions within a distributed file system. Any time an inode is changed, its inode revision number can be incremented by 1. When events within file system are processed causing an inode or a set of inodes to be modified, an event transaction log entry can made. The event transaction log entry can denote a description of the event, a set of modified inode and inode revision number pairs, and a set of parent inode and inode revision number pairs. Entries in the event transaction log can be used to build an inode map for each inode implicated in the event transaction log. The inode map can be used to build a set of direct causal dependencies for each transaction in the event transaction log. The set of direct causal dependencies can be used to generate a causal ordering of the transactions in the event transaction log, that in some implementations, can be made available to external services.

Causally ordering distributed file system events

Implementations are provided herein for utilizing the two-part nature of HDFS protocol communications received in a non-native HDFS environment to use discriminative information learned in the NameNode request to make the client experience more efficient. NameNode requests can be received by any node among a cluster of nodes. It can be appreciated that in some non-native HDFS, clients can communicate with any node among a cluster of nodes to perform transactions and need not first communicate with a NameNode. In addition, any node among the cluster of nodes has access to any data within the HDFS. Thus, upon receiving a NameNode request, the non-native HDFS Cluster of Nodes can more effectively load balance the cluster by directing HDFS clients to connect with Nodes that are less busy than other nodes. In this sense, a more efficient client experience can be offered for HDFS clients within a non-native HDFS environment.

Load balancing Hadoop distributed file system operations in a non-native operating system

Implementations are provided herein for utilizing the two-part nature of HDFS protocol communications received in a non-native HDFS environment to use discriminative information learned in the NameNode request to make the client experience more efficient. NameNode requests can be received by any node among a cluster of nodes. It can be appreciated that in some non-native HDFS, clients can communicate with any nodes among a cluster to perform transactions and need not first communicate with a NameNode. Thus, upon receiving a NameNode request, the non-native HDFS Cluster of Nodes can prefetch data necessary from stable storage to cache memory for efficient reads and/or writes, allocate space on disk for writes, assign the client to communicate with a specific node among the cluster of nodes based on available cluster resources, etc. In this sense, a more efficient client experience can be offered for HDFS clients within a non-native HDFS environment.

Performance of Hadoop distributed file system operations in a non-native operating system

Certificate remoting and recovery may be provided. A computer may identify required security certificates and determine whether at least one required security certificate is not available. If the certificate is not available, the computer may identify a peer server and request the missing certificate from the peer server. The computer may also be operative to receive certificate management instructions from other computers.

Certificate remoting and recovery

Growing community of inventors

Seattle, WA, United States of America

Steven Hubbell