执行摘要：
很长的故事：
我有一个带有单个 ext4 分区的 SSD。该驱动器用于连续存储来自摄像机的视频短片，并且 cron 作业会定期删除最旧的剪辑（在 C 应用程序中，通过调用删除它们remove()）。过了一会儿，有人注意到，虽然应该备份大约 5 天的视频，但几乎没有，但驱动器几乎已满。
我看了一下并天真地尝试删除lost+found，但驱动器仍然已满。所以，我删除了一切( rm -rf *)，但df -i告诉我 91230 个索引节点正在使用中，尽管ls和du根本没有显示任何内容。
e2fsck -fv发现没有错误需要修复（除了lost+found再次创建），并且dumpe2fs双方tune2fs -l都同意df -i已使用的 inode 数量。我尝试过e2fsck -b几个备份超级块，但似乎没有任何区别。
baobab显示与摘要视图中相同的已用空间df，但是当我单击分区查看空间的使用位置时，它只显示空lost+found目录使用的 4.1kB。
问题是不是已删除的文件句柄仍处于打开状态 - 没有任何内容打开。我已经多次安装和卸载该分区，甚至将驱动器取出并将其放入完全不同的机器中。
我知道我可以重新格式化分区并重新开始，但我真的很想了解这里发生了什么以及是否有任何“正确”的方法来解决这个问题 - 我不在乎它是否会带来这些 inode 的文件返回或者正确删除它们，这样它们就不会用完所有空间。
编辑：运行dump创建一个备份文件，其大小大致等于df等人报告的已用空间。然后运行restore到不同的驱动器创建了一系列明显错误的目录（/media/usb0/20150426/10/1_20150426_100125.264/20150426/10/1_20150426_100125.264/并且它继续深入许多层，重复相同的结构），然后打印一堆行，例如：
expected next file 7823361, got 7610674
expected next file 7823361, got 7610675
（第二个数字递增 - 它远远超出了我的终端缓冲区）最后：
cannot find directory inode 11
abort? [yn]
选择n结果更多“找不到目录节点x”，所以我中止了。
放弃并将其视为一种奇怪的文件系统损坏，希望不会再次发生。