这取决于文件系统。
局部性的工作方式是，对于给定的文件，必须在hadoop文件系统接口内实现getblocklocations。例如，您可以看到：
glusterfs hadoop文件系统实现的一个示例实现如下：

public BlockLocation[] getFileBlockLocations(FileStatus file,long start,long len) throws IOException{
    File f=pathToFile(file.getPath());
    BlockLocation[] result=null;

    result=attr.getPathInfo(f.getPath(), start, len);
    if(result==null){
        log.info("Problem getting destination host for file "+f.getPath());
        return null;
    }

    return result;
}

上面您可以看到，文件的元数据是通过特定于gluster的 Package 器提供的，这些 Package 器调用特定于gluster的命令来确定哪些节点存储文件的实际内容。blocklocation[]数组将服务器作为作业调度器的提示，它将尝试将任务降落到拆分确定其块位置的本地位置。
但最终，调度程序的任务是处理拆分，而不是块。因此，拆分可以小于或大于文件系统块。如果它更大，那么很有可能分裂的一部分将通过网络流传输。如果它小得多，那么您可能会获得更多的位置，但可能会以拥有更多的总体任务为代价。
在进行优化时，请记住，每个输入分割最终都会提供给Map器。
在hdfs中，缺省值往往比其他文件系统更好地调整。
通过在与hadoop兼容的文件系统中实现更细粒度的块（getblocklocations），您可以增加块的数量，还可以增加这些块的复制。
增加块的#可以提高特定块在本地上下文中运行的可能性。
此外，您还可以在运行时将#输入拆分（最大值和最小值）切换为mapreduce作业参数的一部分。通过更新此值，您可能会提高性能（即使用计算机），但也可能会降低局部性（更多的拆分意味着，如果某些计算机天生速度更快，mapreduce可能会将拆分流式传输到非局部计算机，从而占用大量任务）