What is so special about DirectRead Registry entry in Flashbackup.
Yesterday evening, I was just going through one of the customer problem. He was having a problem with Flashbackup backup job that was stalled. Most of the time, It was stalled during the time when NBU was mapping information of the file system or Just the mapping was literally too slow. Interesting enough! But after they formatted the drive, copied the data back on the server, took fresh back-up and wow, the problem was somehow resolved.
No rewards for guessing, how it was resolved. It was the MFT file that was highly internally fragmented and it was causing the problem, but you can’t format your drive daily? Can you?
MFT is master file table. MFT is special file in NTFS which exists per volume and always has inode number zero. MFT file is actually an array of indices. Each MFT index has size of 1K. Each file on NTFS volume has one index entry associated in MFT. Sometimes the MFT file has internal fragmentation. Few MFT indices are unallocated in between allocated indices.
Consider following MFT file
|Allocated Indices | Unallocated Indices |Allocated Indices |
|0 1000 | 1001 2000 |2001 3000|
When standard DeviceIOControl code FSCTL_GET_NTFS_FILE_RECORD is used to retrieve unallocated index say 1500, the API internally goes on reading all indices till allocated index is found. In above case if index 1500 is requested then the API will read all indices between 1000 and 1500 and will eventually return index 1500 and still Unallocated. This produces a performance hit.
In such scenarios reading directly from volume is way more efficient. FlashBackup provides you a Registry hack (another way to read MFT). We call it as “DirectRead” because standard DeviceIOControl code FSCTL_GET_NTFS_FILE_RECORD gets used only once and later all MFT indices are retrieved using pure volume read. Use the smartest way to Back-up your data. Now the question is how to enable it:
Add Following Registry Key:
Under HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\VxMS
Add Dword value called DirectRead Give it value of 1.
Other choices: Defragmentation can be a option and may improve the performance. There are lot of scenario where you can see FlashBackup is not doing fast mapping and look like has slowed down from past.
Watch out this space for the discussion!!
No rewards for guessing, how it was resolved. It was the MFT file that was highly internally fragmented and it was causing the problem, but you can’t format your drive daily? Can you?
MFT is master file table. MFT is special file in NTFS which exists per volume and always has inode number zero. MFT file is actually an array of indices. Each MFT index has size of 1K. Each file on NTFS volume has one index entry associated in MFT. Sometimes the MFT file has internal fragmentation. Few MFT indices are unallocated in between allocated indices.
Consider following MFT file
|Allocated Indices | Unallocated Indices |Allocated Indices |
|0 1000 | 1001 2000 |2001 3000|
When standard DeviceIOControl code FSCTL_GET_NTFS_FILE_RECORD is used to retrieve unallocated index say 1500, the API internally goes on reading all indices till allocated index is found. In above case if index 1500 is requested then the API will read all indices between 1000 and 1500 and will eventually return index 1500 and still Unallocated. This produces a performance hit.
In such scenarios reading directly from volume is way more efficient. FlashBackup provides you a Registry hack (another way to read MFT). We call it as “DirectRead” because standard DeviceIOControl code FSCTL_GET_NTFS_FILE_RECORD gets used only once and later all MFT indices are retrieved using pure volume read. Use the smartest way to Back-up your data. Now the question is how to enable it:
Add Following Registry Key:
Under HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\VxMS
Add Dword value called DirectRead Give it value of 1.
Other choices: Defragmentation can be a option and may improve the performance. There are lot of scenario where you can see FlashBackup is not doing fast mapping and look like has slowed down from past.
Watch out this space for the discussion!!
Published 16 years ago
Version 1.0
