估计NTFS卷上的USN记录数 [英] Estimate the number of USN records on NTFS volume

问题描述

首次使用USN日志时，必须使用FSCTL_ENUM_USN_DATA控制代码枚举卷的整个USN记录集.通常这是一个冗长的操作.

是否有一种方法可以在运行卷之前估计该卷上的记录数，以便可以显示进度?

我猜整个卷的USN数据都是从MFT生成的，每个文件一个记录(大约).因此，也许可以估算MFT中活动文件的数量.

解决方案

您可以使用FSCTL_GET_NTFS_VOLUME_DATA来获取MFT的长度(以字节为单位).如果将其与所选代表卷上的记录数进行比较，则可以估计单个MFT记录的平均长度，并以此来计算特定卷上的记录数的估计值.

由于MFT包含(例如)每个文件的安全性信息，因此平均长度在卷与卷之间会有很大差异，因此我认为您只能得到数量级的准确性，但可能就足够了在大多数情况下.

另一种方法是假设文件参考号线性增加，这是正确的.您可以使用FSCTL_ENUM_USN_DATA来查找是否存在参考号高于特定猜测的文件；您只需不超过128个猜测即可确定实际的最大参考数字.这样至少可以在任何给定点为您提供0到100之间的百分比完整度，虽然它不是完全统一的，但是进度条却从来都不是. :-)

其他:

更仔细地看，在Windows 7 x64上，由FSCTL_ENUM_USN_DATA返回的下一个id"字段(第一个USN_RECORD结构之前返回的四字)毕竟不是文件引用号，而是文件记录段号.因此，如您所见，返回的最后一个ID号乘以BytesPerFileRecordSegment(1024)，等于MftValidDataLength.

文件参考号似乎由两部分组成.低六个字节包含文件记录段号.从每个请求返回的第一条记录始终具有一个FRN，其段号与输入给StartFileReferenceNumber的下一个ID"相同，但StartFileReferenceNumber为零时的第一次调用除外.前两个字节包含未指定的附加信息，永远不会为零.

似乎FSCTL_ENUM_USN_DATA接受文件记录段号(在此情况下，前两个字节为零)或文件参考号(在此情况下，前两个字节为非零)./p>

一个奇怪的是，我找不到两个记录段号相同的记录.这表明每个文件记录在MFT中至少使用了1K，这似乎是不合理的.

无论如何，结果是，将下一个id"乘以BytesPerFileRecordSegment并将其除以MftValidDataLength可能是明智的，只要您能很好地应对，如果返回的结果是荒谬的即可.

When the USN journal is used for the first time, the volume's entire set of USN records must be enumerated using the FSCTL_ENUM_USN_DATA control code. This is usually a lengthy operation.

Is there a way to estimate the number of records on the volume prior to running it, so progress can be displayed?

I'm guessing the USN data for the entire volume is generated from the MFT, with one record per file (approximately). So perhaps a way to estimate the number of active files in the MFT would work.

解决方案

You can use FSCTL_GET_NTFS_VOLUME_DATA to get the length in bytes of the MFT. If you compare this to the number of records on a selection of representative volumes, you could estimate the average length of a single MFT record and use this to calculate an estimate for the number of records on a particular volume.

Because the MFT contains (for example) the security information for every file, the average length will vary significantly from volume to volume, so I think you'll only get order-of-magnitude accuracy, but it may be good enough in most cases.

Another approach would be to assume that the file reference numbers increase linearly, which is roughly true. You can use FSCTL_ENUM_USN_DATA to find out whether there are any files with a reference number above a particular guess or not; you'd need no more than 128 guesses to determine the actual maximum reference number. That would at least give you a percentage complete between 0 and 100 at any given point, it wouldn't be entirely uniform but then progress bars never are. :-)

Additional:

Looking more closely, on Windows 7 x64 the "next id" field returned by FSCTL_ENUM_USN_DATA (the quadword returned before the first USN_RECORD structure) isn't a file reference number after all, but the file record segment number. So, as you observed, the last id number returned, multiplied by BytesPerFileRecordSegment (1024), is equal to MftValidDataLength.

File reference numbers appear to be made up of two parts. The low six bytes contain the file record segment number. The first record returned from each request always has a FRN whose segment number is the same as the "next id" fed into StartFileReferenceNumber, except for the first call when StartFileReferenceNumber is zero. The upper two bytes contain unspecified additional information, which is never zero.

It seems that FSCTL_ENUM_USN_DATA accepts either a file record segment number (in which case the top two bytes are zero) or a file reference number (in which case the top two bytes are nonzero).

One oddity is that I can't find two records with the same record segment number. This suggests that each file record is using at least 1K in the MFT, which doesn't seem reasonable.

Anyway, the upshot is that it is probably sensible to multiply the "next id" by BytesPerFileRecordSegment and divide it by MftValidDataLength to get a percentage completed, so long as you cope gracefully if this returns a nonsensical result.

这篇关于估计NTFS卷上的USN记录数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！