Map-reduce ready distributed file system
A map-reduce compatible distributed file system that consists of successive component layers that each provide the basis on which the next layer is built provides transactional read-write-update semantics with file chunk replication and huge file-create rates. Containers provide the fundamental basis for data replication, relocation, and transactional updates. A container location database allows containers to be found among all file servers, as well as defining precedence among replicas of containers to organize transactional updates of container contents. Volumes facilitate control of data placement, creation of snapshots and mirrors, and retention of a variety of control and policy information. Also addressed is the use of distributed transactions in a map-reduce system; the use of local and distributed snapshots; replication, including techniques for reconciling the divergence of replicated data after a crash; and mirroring.
1. A computer implemented map reduce method comprising:
maintaining information about where each of a plurality of containers is located in a container location database (CLDB), wherein a storage pool contains zero or more containers, wherein a cluster node in a plurality of cluster nodes contains one or more storage pools;
structuring data within said containers using a plurality of inodes;
replicating said containers to other cluster nodes with one container designated as master for each replication chain;
storing data in said CTDB as modes in well known containers;
maintaining a database in CLDB nodes, wherein said database contains at least following information about all of said containers:
nodes that have replicas of a container,
an ordering of a replication chain for each container,
wherein updates to said container are sent to a master container for said updated container, and wherein changes to content of said container are propagated to said replicas of said container by said master container;
storing in said CLDB a location of all replicas of said container, a structure of a replication for said container, and an epoch number for each container, wherein said epoch number is incremented each time said structure of said replication for said container is changed, and wherein an epoch's changes are noted in a transaction history for each version of said container and gaps are inserted whenever said master container is noted in said replication chain; and
tracing back through transactions that have been applied to each copy when examining said master container and target copies of a same container to determine a point in a history of two containers when the two containers were identical.
2. The method of claim 1 , further comprising:
run-length encoding a set of committed transactions, wherein an on-disc state is updated only when a new epoch is begun as a new master is designated, and wherein the transactions are identified by said epoch in which the transactions were performed, as well as by a transaction counter in said container.
3. The method of claim 1 , wherein a target container is brought up to date relative to said master container by undoing any changes made to a secondary version of said container because changes on said target container may not all have been applied to said master container.
4. The method of claim 3 , wherein once a common ancestor transaction is identified, said secondary version of said container is scanned to find all blocks that have been modified since said common ancestor transaction;
wherein as these blocks are found, said target container over-writes the blocks by requesting these same blocks from said master container;
wherein all blocks in said target container are left either in a state that all blocks in said target container had as of a common ancestor state or in a later state present on said master container; and
wherein all blocks are updated to a current state of said master container.