为什么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，其原因是因为数据库不断增长，碎片较多，片断化导致元数据量大，位置分散，无法一次性完成释放等操作。
