估計NTFS捲上的USN記錄數

首次使用USN日誌時，必須使用FSCTL_ENUM_USN_DATA控制碼枚舉該卷的整個USN記錄集。這通常是一個漫長的操作。估計NTFS捲上的USN記錄數

有沒有一種方法可以在運行之前估計捲上的記錄數，因此可以顯示進度？

我猜整個卷的USN數據是從MFT生成的，每個文件一個記錄（大約）。因此，估計MFT中活動文件數量的方法可能會奏效。

2012-07-04 Edmund

FSCTL_ENUM_USN_DATA列出了MFT的內容，而不是USN日誌的內容（您將使用FSCTL_READ_USN_JOURNAL）。所以，是的，它包含捲上每個文件和目錄的一個條目。我不知道有什麼方法來估計參賽作品的數量。而不是一個進度條或百分比，也許只是顯示目前處理的文件/目錄的數量會做什麼？ –

問：爲什麼你想枚舉整個MFT？這可能沒有必要。這個答案可能是有用的：http://stackoverflow.com/a/7459109/886887 –

這正是我的理解（或至少猜測）。顯示點數可能不得不做，但我仍然願意提供任何可能大致接近點數的建議。 – Edmund

您可以使用FSCTL_GET_NTFS_VOLUME_DATA來獲取MFT的字節長度。如果您將其與選定代表性捲上的記錄數進行比較，則可以估算單個MFT記錄的平均長度，並使用它計算特定捲上記錄數的估計值。

因爲MFT包含（例如）每個文件的安全信息，所以平均長度在每個卷中都會有很大差異，所以我認爲你只能得到數量級的精度，但它可能是好的在大多數情況下足夠。

另一種方法是假定文件引用數字線性增加，這大致爲真。您可以使用FSCTL_ENUM_USN_DATA來確定是否有任何文件的參考號超出特定的猜測值;您需要不超過128次猜測才能確定實際的最大參考編號。這至少會給你在任何給定點上0到100之間的百分比，它不會完全統一，但進度條永遠不會。 :-)

附加：

仔細看，在Windows 7 x64中通過FSCTL_ENUM_USN_DATA（四字第一USN_RECORD結構之前返回）返回的「下一個ID」字段不是一個文件引用數字畢竟是文件記錄段號碼。因此，如您所見，返回的最後一個id號乘以BytesPerFileRecordSegment（1024），等於MftValidDataLength。

文件引用號碼看起來由兩部分組成。低六個字節包含文件記錄段號。從每個請求返回的第一條記錄始終有一個FRN，其段編號與輸入到StartFileReferenceNumber中的「下一個ID」相同，但StartFileReferenceNumber爲零時的第一個調用除外。上面的兩個字節包含未指定的附加信息，從不爲零。

似乎FSCTL_ENUM_USN_DATA可以接受的文件記錄段號（在這種情況下，頂部的兩個字節是零）或文件參考號（在這種情況下，頂部的兩個字節是非零）。

奇怪的是，我找不到具有相同記錄段編號的兩條記錄。這表明每個文件記錄在MFT中至少使用1K，這似乎不合理。

無論如何，結果是，將BytesPerFileRecordSegment乘以「next id」並將其除以MftValidDataLength以獲得完成百分比可能是明智的，只要您優雅地應對，如果這返回了無意義的結果。

來源

2012-07-05 04:36:25

嗨哈利，我做了一些實驗，發現了一件有趣的事情 - FSCTL_ENUM_USN_DATA實際上返回MFT偏移量作爲下一個「StartFileReferenceNumber」或USN（取決於您閱讀的MSDN文檔的哪一部分！）。這個數字相對較小，與FRN或USN沒有任何關係。所以我所做的是使用FSCTL_GET_NTFS_VOLUME_DATA來獲得MFT的大小，然後將這個MFT pos作爲進度的指標。 – Edmund

在我的系統（Windows 7 SP1）上，FSCTL_ENUM_USN_DATA返回的數字肯定是文件引用號。我一直認爲它總是必須的，因爲這就是你在下一次調用時爲StartFileReferenceNumber傳入的內容。你在運行什麼操作系統？（「參考數字」實際上是一個偏移量是有意義的，但我得到的數字不是，因爲它們通常是連續的。） –

這是我的工作機器，WinXP SP2。由於這不是記錄的行爲，我可能不應該依賴它，我想它不會在7（我會嘗試）。返回的USN記錄的FileReferenceNumber字段不正確（雖然它們似乎是近似順序）。 – Edmund

估計NTFS捲上的USN記錄數

回答

相關問題