为什么NTFS删除超过4G大文件或数据库文件后FILE RECORD大小表现为0?


答:NTFS删除一个文件,必须要完成如下几个流程,才算完结:

1、更改文件系统$bitmap,释放空间

2、更改$mft filerecord项的属性为删除

3、更改$mft:$bitmap的位图信息为0,释放这个filerecord的占用空间

4、清除目录链表中关于本文件的item信息。

        这个流程是理想状态下的处理规则,但实际上,最头疼的是OS要考虑这个问题:如果在上述4个步骤中出现中断(如突然断电、死机等),如何让下次操作时能够继续,或者维系文件系统还是一致的(最简单的,如果文件删除了,但目录还在,那总是不合适的,全盘李检测一次又太消耗时间,而且到底谁错了,有时候也分不清),为了解决这个问题,NTFS引入了$logfile,即日志,简单说就是为正在执行的一个完整IO运作(如删除一个文件)事先记录一下状态,如果没做成功,下回直接回滚回没做成功的状态即可。

        可是问题又来了,如果某个文件太大,或者存储链表太长(即碎片太多)。记录这个文件元信息部分就会变得很大,比如一个文件大小是4G,按4K块大小算,连续的位图至少也得有1M,为了不至于在日志文件中保存太大的信息(比如一个4T的文件,先保存1g的位图,太慢且变数又增大了),NTFS对于复杂文件或大文件是采取分批次处理的:即某个文件可能是不断地被变小,变小,直至变0。

        为了维持操作的一致性。猜想,NTFS设了两种情况,如果是判断可以一次日志记录即够完成某个IO原子操作的,就不用清除filerecord的大小和位置信息(runlist)了。但如果ntfs无法一次日志完成一个IO原子操作,则需要分成多个独立的IO原子操作,每个IO原子操作记录一次日志,完成时更新成新状态——这样一来,删除一个大文件或多碎片的文件,最后一次IO原子操作后,就会清除为0大小,RUNLIST清空状态。

        这个问题中,4G其实也不是变数,猜测来源于4K块大小,和文件一次释放1M个簇范围的片区导致。数据库往往不容易恢复,大小即使小于4G,其原因是因为数据库不断增长,碎片较多,片断化导致元数据量大,位置分散,无法一次性完成释放等操作。

                                                                                                       -------北亚数据恢复中心 张宇