一种新型的EC编码，LRC码，基于RS码的改进，特点介于RS和副本之间。

传统的Reed-Solomon编码有个缺点是，单个分片的数据丢失就需要读取多个数据分片就行数据修复。
例如10:6的RS码，前10个分片有一个分片数据丢失，那么需要先从其他的分片中至少读取10个分片数据才能计算出丢失的数据。

LRC（locally repairable codes）是基于RS编码改进，可以有效减少数据修复时的系统负载。

当然，在相同数据可靠性的情况下，LR占用的物理空间略大，比三副本方式还是小很多。

例如：
   计算10:6:2的LRC码，首先按照10:6的比例计算出RS码，得到chunk分片X1、X2、......X10、Y1、Y2、......Y6，
   然后取Z1=X1+X2+......+X5,Z2=X6+......+X10。
   X1、X2、......X10、Y1、Y2、......Y6、Z1、Z2就构成了（10:6:2）的LRC码。 如果X1、X2、......X10中有一个分片出现数据丢失，那么只需要读取（前5个分片中的4个+Z1）或者（后5个分片中的4个+Z2），就可计算出丢失的分片。
   而传统的RS码则需要读取10个chunk分片。
   此时，LRC码可以节省二分之一的磁盘i/o和节点间的网络通信带宽。
LRC的数据可靠性低于RS高于副本，数据修复的性能低于副本高于RS，是一种折中的算法。

目前LRC编码算法在最新的Hadoop-HDFS中已经实现，由facebook贡献。

windows的azure是利用了类似的技术，微软称之为local reconstruton code。

当节点数量超过1000，单点故障是常态，系统需要大量的临时性的数据修复（很多时候节点是指暂时性离线，并不需要做持久性数据恢复），

因此LRC码在hadoop环境下的作用比较明显。

个人感觉，对规模几十个节点，功能只是存储的nas集群来说，LRC码的作用并没有这么大。

EMC的atmos和isilon中采用的还是传统的RS码。