NTFS: deleting corrupt attribute record (128, $J)
I'm trying to do a really simple conversion from Windows Server 2008 R2 SP1 to ESXi machine version 8. It seems to copy okay, but on the first VM boot it does an NTFS disk check and finds a bunch of errors.
All major services are stopped (APC Powerchute, Windows Deployment Services, Backup Exec Agent) and the antivirus uninstalled. chkdsk has been run on the source hardware and found no problems.
And yet after the migration I see this on first boot:
Checking file system on C:
The type of the file system is NTFS.
One of your disks needs to be checked for consistency. You may cancel the disk check, but it is strongly recommended that you continue.
Windows will now check the disk.
CHKDSK is verifying files (stage 1 of 3)...
The attribute of type 0x80 and instance tag 0x3 in file 0xe08c has allocated length of 0x1fec00000 instead of 0x1fecc0000.
Deleting corrupt attribute record (128, $J) from file record segment 57484.
Attribute record of type 0x80 and instance tag 0x3 is cross linked starting at 0x11a for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3 in file 0xe120 is already in use.
Deleting corrupt attribute record (128, "") from file record segment 57632.
199936 file records processed.
File verification completed.
885 large file records processed.
0 bad file records processed.
0 EA records processed.
104 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
262480 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 3)...
199936 file SDs/SIDs processed.
Cleaning up 8 unused index entries from index $SII of file 0x9.
Cleaning up 8 unused index entries from index $SDH of file 0x9.
Cleaning up 8 unused security descriptors.
Security descriptor verification completed.
Inserting data attribute into file 57632.
31274 data files processed.
CHKDSK is verifying Usn Journal...
Creating Usn Journal $J data stream
Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
70936575 KB total disk space.
50582732 KB in 152611 files.
97136 KB in 31274 indexes.
0 KB in bad sectors.
269927 KB in use by the system.
65536 KB occupied by the log file.
19986780 KB available on disk.
4096 bytes in each allocation unit.
17734143 total allocation units on disk.
4996695 allocation units available on disk.
Internal Info:
00 0d 03 00 59 ce 02 00 ac 1e 05 00 00 00 00 00 ....Y...........
d1 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 ....h...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Windows has finished checking your disk.
Please wait while your computer restarts.
There is absolutely NO WAY that I am going to use this resulting conversion as our primary organization file server. Such corruption of the NTFS partition data is completely unacceptable. I have no way of knowing what "file record 57484 / 57632" are and if they are critical to the operation of the server.
Though I expect I already know what the problem is, and I cannot solve it by using VMWare Converter running on the Windows I'm trying to migrate.
Trying to copy a file system while it is in use is just inviting disaster because as you're copying data, something before or after wherever the copy is occurring may change so that the final copy result ends up being corrupted.
The only way to really prevent this mid-copy data corruption is to copy the partitions when they are not in use.
0 Kudos
5 Replies
VMware Employee
06-22-2015 09:08 AM
Could you upload log bundle?
0 Kudos
Contributor
06-22-2015 02:04 PM
POCEH, is there a way to directly send the logs to you? I don't know if they contain any sensitive information that could be used by remote hackers, but I'd hate to accidentally share that.
The source converter logs which I am putting all in a single ZIP, contain I believe three attempts to convert the source 2008 R2.
The first time the converter showed corruption, I hadn't run chkdsk on the source before conversion. I then ran chkdsk and it did find some stuff but nothing major on the source. The conversion attempts after that were done with chkdsk saying the source drives were okay, but still finding corruption on the target VM after conversion. Also did synchronize after convert with all attempts.
The last convert attempt I did not resize the volumes via converter during conversion, but was planning to do that later myself using PXE / WinPE and diskpart, if the conversion had no errors after completion.
.
0 Kudos
VMware Employee
06-23-2015 01:06 AM
Yes, you can send me your logs in PM, check the converter-worker logs are included, they are most important in this case.
0 Kudos
Contributor
06-23-2015 02:57 PM
Sorry I've looked all over this VMWare Communities web interface, nowhere is there a "Send personal message" ability.
Clicking on your profile image does not reveal such an option to me.
0 Kudos
VMware Employee
06-23-2015 03:14 PM
The interface has been changed, After selecting his profile, select 'documents' on the top menu bar, then 'uploaded file' on the left. Select the 'hidden' radio button to make it private (I haven't actually tested it)
对应的中文
我试图做一个非常简单的从 Windows Server 2008 R2 SP1 到 ESXi 机器版本 8 的转换。它似乎可以复制，但在第一次 VM 启动时它会进行 NTFS 磁盘检查并发现一堆错误。
停止所有主要服务（APC Powerchute、Windows 部署服务、Backup Exec 代理）并卸载防病毒软件。已经在源硬件上运行过chkdsk，没有发现问题。
然而在迁移之后我在第一次启动时看到了这个：
检查 C: 上的文件系统
文件系统类型为NTFS。
您的一个磁盘需要检查一致性。您可以取消磁盘检查，但强烈建议您继续。
Windows 现在将检查磁盘。
CHKDSK 正在验证文件（第 1 阶段，共 3 阶段）...
文件 0xe08c 中类型 0x80 和实例标记 0x3 的属性分配的长度为 0x1fec00000 而不是 0x1fecc0000。
从文件记录段 57484 中删除损坏的属性记录 (128, $J) 。
类型 0x80 和实例标记 0x3 的属性记录从 0x11a 开始交叉链接，可能为 0x1 簇。
文件 0xe120 中类型为 0x80 和实例标记为 0x3 的属性占用的某些集群已在使用中。
从文件记录段 57632 中删除损坏的属性记录（128，“”） 。
处理了 199936 条文件记录。
文件验证完成。
处理了 885 条大文件记录。
处理了 0 个错误文件记录。
处理了 0 个 EA 记录。
处理了 104 条重新解析记录。
CHKDSK 正在验证索引（第 2 阶段，共 3 阶段）...
处理了 262480 个索引条目。
索引验证完成。
扫描了 0 个未编制索引的文件。
已恢复 0 个未编制索引的文件。
CHKDSK 正在验证安全描述符（第 3 阶段，共 3 阶段）...
处理了 199936 个文件 SD/SID。
从文件 0x9 的索引 $SII 中清除 8 个未使用的索引条目。
从文件 0x9 的索引 $SDH 中清除 8 个未使用的索引条目。
清理 8 个未使用的安全描述符。
安全描述符验证已完成。
将数据属性插入文件 57632。
处理了 31274 个数据文件。
CHKDSK 正在验证 Usn 日志...
创建 Usn Journal $J 数据流
Usn 日志验证已完成。
CHKDSK 发现在卷位图中标记为已分配的可用空间。
Windows 已对文件系统进行了更正。
70936575 KB 总磁盘空间。
152611 个文件中的 50582732 KB。
31274 个索引中的 97136 KB。
0 KB 坏扇区。
系统正在使用 269927 KB。
日志文件占用 65536 KB。
磁盘上有 19986780 KB 可用。
每个分配单元 4096 字节。
磁盘上的总分配单元数为 17734143。
磁盘上有 4996695 个分配单元可用。
内部信息：
00 0d 03 00 59 ce 02 00 ac 1e 05 00 00 00 00 00 ....Y......
d1 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 ....h......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
Windows 已完成磁盘检查。
计算机正在重新启动，请稍候。
我绝对不会将此转换结果用作我们的主要组织文件服务器。NTFS 分区数据的这种损坏是完全不能接受的。我无法知道“文件记录 57484 / 57632”是什么，以及它们是否对服务器的运行至关重要。
虽然我希望我已经知道问题出在哪里，但我无法通过使用在我尝试迁移的 Windows 上运行的 VMWare Converter 来解决它。
试图在文件系统正在使用时复制它只会招致灾难，因为在复制数据时，复制发生之前或之后的某些内容可能会发生变化，从而导致最终复制结果被破坏。
真正防止这种中间复制数据损坏的唯一方法是在分区不使用时复制它们。
POCEH，有没有办法直接把日志发给你？我不知道它们是否包含任何可能被远程黑客使用的敏感信息，但我不想不小心分享这些信息。
我将全部放在一个 ZIP 中的源转换器日志包含我相信转换源 2008 R2 的三次尝试。
第一次转换器显示损坏时，我在转换前没有在源上运行 chkdsk。然后我运行了 chkdsk，它确实找到了一些东西，但在源代码上没有什么大不了的。之后的转换尝试是通过 chkdsk 完成的，说源驱动器没问题，但转换后仍然在目标 VM 上发现损坏。转换后也进行了所有尝试的同步。
最后一次转换尝试我没有在转换期间通过转换器调整卷的大小，但我计划稍后使用 PXE / WinPE 和diskpart自己做，如果转换完成后没有错误。
.
界面已更改，选择他的个人资料后，在顶部菜单栏中选择“文档”，然后在左侧选择“上传的文件”。选择“隐藏”单选按钮将其设为私有（我还没有实际测试过）
NTFS: deleting corrupt attribute record (128, $J) - VMware Technology Network VMTN
扫一扫
828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
