Hadoop 2.7.3下HDFS删除正在写入文件的异常问题咨询

这其实是HDFS Lease机制设计和删除操作逻辑共同导致的正常行为，在Hadoop 2.7.3里完全符合预期，我来给你拆解清楚：

1. Lease机制的核心目标不是阻止删除 #

Lease机制的初衷是防止多个客户端同时写入同一文件，确保数据一致性——它会给当前写入的客户端分配一个lease，在lease有效期内，其他客户端无法获取写入权限。但这个机制不限制删除操作：

• 当客户端B发起删除请求时，NameNode只会校验B是否有该文件的删除权限，不会检查文件是否被持有active lease。只要权限通过，NameNode就会立即将文件从命名空间中移除（如果开启了Trash，就先移到Trash目录）。

2. 写入期间无需和NameNode频繁交互 #

客户端A在写入文件的过程中（包括write()和flush()操作），主要是和DataNode直接通信：

• 数据会被写入到DataNode的本地块中，flush只是将内存中的数据刷到DataNode的磁盘，这一阶段不需要向NameNode发送请求。
• 此时文件虽然已经被NameNode标记删除，但DataNode上的物理块还没有被清理（HDFS的块回收是异步的，需要等lease过期或者客户端主动close后才会触发），所以A依然能继续写入数据。

3. Close操作才会触发NameNode校验 #

当A调用os.get.close()时，会触发以下流程：

1. A向NameNode发送文件写入完成的通知，请求更新文件元数据并释放lease。
2. NameNode检查文件的状态，发现对应的inode已经不存在（因为已经被B删除），于是抛出如下异常：

org.apache.hadoop.hdfs.server.namenode.LeaseExpiredException: No lease on /user/lock.txt (inode 643845185): File does not exist. Holder DFSClient_NONMAPREDUCE_-1636584585_1 does not have any open files

此时文件的lease已经失去了对应的载体，自然会提示文件不存在、lease无效。

4. 关于你测试代码中的recoverLease #

你在删除逻辑里尝试调用recoverLease，但这个方法是用来在客户端异常退出时，让其他客户端接管文件的写入权限的。而你的场景中，文件已经被NameNode从命名空间移除，对应的元数据和lease都已不存在，所以recoverLease必然会失败，无法通过这个方式"抢"到lease来删除文件（实际上你已经成功删除了文件，后续的删除请求都是无效的）。

补充验证 #

你可以在测试中加入一个步骤：在B删除文件后，立即用fs.getFileStatus()去查询文件状态，会发现NameNode已经返回文件不存在；但此时A的写入操作依然能正常执行，直到close时才报错，这正好验证了上面的逻辑。

内容的提问来源于stack exchange，提问作者salexinx