答案是查看编辑日志中的信息。如果编辑日志中没有可用的信息，那么当我们将新文件写入hdfs时，这个问题适用于用例。当namenode运行时，如果删除fsimage文件并尝试读取它能够读取的hdfs文件。
从正在运行的namenode中删除fsimage文件不会导致读/写操作出现问题。重新启动namenode时，会出现错误，说明找不到映像文件。
让我试着给你更多的解释来帮助你。
只有在启动时hadoop才会查看fsimage文件，如果它不在那里，namenode不会出现并记录namenode的格式。
hadoop format-namenode命令创建fsimage文件（如果存在编辑日志）。namenode启动后，从编辑日志中获取元数据（如果在编辑日志中找不到信息，则通过fsimage文件搜索）。所以fsimage只是作为上次保存信息的检查点。这也是次要节点从编辑日志保持同步（在1小时/1百万个事务之后）的原因之一，以便从最后一个检查点启动时不需要太多同步。
如果要打开safemode（命令：hdfs dfsadmin-safemode enter）并使用savenamespace（命令：hdfs dfsadmin-savenamespace），它将显示下面提到的日志消息。

2014-07-05 15:03:13,195 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Saving image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 using no compression
2014-07-05 15:03:13,205 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 of size 288 bytes saved in 0 seconds.
2014-07-05 15:03:13,213 INFO org.apache.hadoop.hdfs.server.namenode.NNStorageRetentionManager: Going to retain 2 images with txid >= 0
2014-07-05 15:03:13,237 INFO org.apache.hadoop.hdfs.server.namenode.FSEditLog: Starting log segment at 170

我回答这个问题有点晚了，但我认为这值得一个更明确的回答。
如果我说得对，你想知道，如果元数据存储在编辑日志中，为什么在删除一个文件后，当我们试图列出旧文件路径时，它会抱怨它不存在或者其他什么？namenode如何知道文件或目录已被删除而不读取编辑日志？
hadoop权威指南第11章中确实提到了这一点：
当文件系统客户机执行写操作（如创建或移动文件）时，事务首先记录在编辑日志中。namenode还有一个文件系统元数据的内存表示，它在修改编辑日志后更新。内存中的元数据用于服务读取请求。
话虽如此，答案很简单，因为更新edit log namenode之后，会更新内存中的表示。因此，当接收到读取请求时，它知道该文件或目录已被删除，并会抱怨该文件或目录不存在。

整个文件系统名称空间，包括“块到文件的Map”和文件系统属性，都存储在一个名为fsimage的文件中。请记住，“块到文件的Map”是fsimage的一部分。它存储在内存和磁盘中。hadoop还将与fsimage一起存储在内存中，通过块报告进行块到数据节点的Map，同时名称节点（重新）启动并定期进行。因此，当您将文件移动到其他位置时，将在磁盘上的编辑日志中对此进行跟踪，并且当数据节点将块报告发送到namenode时，namenode将获得块在群集中位置的最新视图。因此，由于block report更新了“块到datanodes的Map”，您将无法看到旧路径中的数据。但请记住，更新只发生在内存中。现在，经过一定时间后，无论是在检查点中还是在重新启动名称节点时，磁盘上的editlogs已经有了您所做的更新（在您移动文件的情况下）将与磁盘上的旧fsimage合并并创建一个新fsimage。现在这个更新的fsimage将被加载到内存中，相同的过程将重复。