[DiracDeBroglie]

Hi,

One can change the MFT zone reservation by altering the registry key NtfsMftZoneReservation. Details are given in:
http://support.microsoft.com/kb/174619

Under WinXP, with NtfsMftZoneReservation set to 4, the MFT zone of a newly formatted volume takes up almost 50% of the volume size. One can check that using UltraDefrag, see links below.

Setting NtfsMftZoneReservation=1, using regedit; rebooting the computer and checking again the MFT zone of the volume with UltraDefrag reveals that the original MFT zone has shrunk with something like 50% (or more) although I have not at all reformatted the volume. If I then reformat the drive, the new MFT zone shrinks even more but then to its normal size (12% or so), consistent with NtfsMftZoneReservation=1.

If I then set NtfsMftZoneReservation=4, reboot computer, check the MFT zone of the volume, then the MFT zone has expanded by itself while the empty volume has not at all been reformatted. It looks like the filesystem is changing the size of the MFT zone of the (empty) volumes by itself after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume

Do I get it completely wrong here?? Did I mis something? Is there anyone who could confirm this by doing extra tests?

I have noticed exactly the same problem with Windows 7. Also there the MFT zone of empty volumes gets altered after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume.

Johan

http://ultradefrag.s...t/en/index.html
http://sourceforge.n...-release/5.0.2/

This post has been edited by DiracDeBroglie: 13 February 2012 - 09:24 AM

[jaclaz]

DiracDeBroglie, on 13 February 2012 - 09:22 AM, said:

If I then set NtfsMftZoneReservation=4, reboot computer, check the MFT zone of the volume, then the MFT zone has expanded by itself while the empty volume has not at all been reformatted. It looks like the filesystem is changing the size of the MFT zone of the (empty) volumes by itself after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume

Do I get it completely wrong here?? Did I mis something? Is there anyone who could confirm this by doing extra tests?

I have noticed exactly the same problem with Windows 7. Also there the MFT zone of empty volumes gets altered after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume.

It seems to me perfectly "natural".
You have an EMPTY volume.
You tell the OS to expand the MFT zone.
It finds a lot of free space ("on the right") to expand the MFT zone, it does it.
Of course there is NO need whatsoever to reformat.
The tests should be made with a "filled" volume (actually all is needed is to have a few files right after the previously set MFT reserved zone.
But in this case there will be no need to reformat, most probably the files will be moved "further on the right".
A nice experiment could be instead of rebooting to run CHKDSK on the volume.

Tools mentioned here may come handy:
http://reboot.pro/15086/page__st__25

jaclaz

[DiracDeBroglie]

What should the attributes be of CHKDSK? /R or /X or something else?
Johan

This post has been edited by DiracDeBroglie: 16 February 2012 - 01:36 PM

[jaclaz]

DiracDeBroglie, on 16 February 2012 - 01:18 PM, said:

What should the attributes be of CHKDSK? /R or /X or something else?
Johan

I have no idea , ideally you should try by steps:

• CHKDSK
  
• CHKDSK /F
  
• CHKDSK /X (only Windows 2003 and later)

I would "bet" on CHKDSK /F, but it is possible that CHKDSK only is enough.

Another test would be simply UNmounting the volume and re-mounting it.

I would try first with MOUNTVOL (available since NT or 2K)

On Server 2008 and 7, another approach could be setting offline the actual disk:
http://reboot.pro/8200/page__st__39

If you prefer, I suspect that the reboot is not vital but having CHKDSK check the volume or Mount Manager re-discover it should be enough for the new MFT reservation to be enabled.

And yet another test could be defrag.

jaclaz

This post has been edited by jaclaz: 16 February 2012 - 01:51 PM

[DiracDeBroglie]

Subject: Enabling new MFT zone reservation *without* reformatting the volume.

In Win7, I've used CHKDSK and MOUNTVOL with several attributes; also Diskpart offine/online I used, and I ejected and physically reconnected my 2TB USB drive several times. All those commands work perfectly but the newly set MFT zone reservation was definitely NOT enabled after using those commands. The only way to get the new MFT zone reservation enabled, was by rebooting the computer.

In WinXP I used CHKDSK on the volumes but also here the new MFT zone reservation didn't get enabled; only reboot of the computer did the job.

As for the expansion and the shrinking of the MFT zone reservation (without reformatting, and after rebooting), shrinking is never a problem. However, in case of expanding the MFT zone reservation, it did expand up until the foreseen size determined by NtfsMftZoneReservation=1->4, or until the expansion of the MFT zone bumped into at least one cluster with a file (system of user). Hence that any MFT zone that is encapsulated by files, won't expand at all beyond those files; files were definitely *not* moved so to expand the MFT zone.

I noticed something else, and I'm not sure what the implications could be. I reformatted the test volumes (2TB USB drive) on my WinXP laptop with NtfsMftZoneReservation=1 (which is the default value). Then I connected the drive to my Win7 laptop and all MFT zone reservations got shrunk (a lot). New userdata was then put right after the shrunk MFT zone, thereby blokking any expansion of the MFT zone when connection my 2TB drive back to my WinXP laptop.

I don't know what to think of this; I find it quite obvious that different volumes can have different MFT zone reservations set by the user, and those MFT zone reservation should not change when NtfsMftZoneReservation gets a new value (1->4). I find it obvious that the MFT zone reservation *only* changes during (re)formatting of a volume. The behavior of Win7 and WinXP is consistent with http://support.microsoft.com/kb/174619 , though. However, I am still in the opinion that the automatic resizing of the MFT zone for ALL volumes (wihout (re)formatting) in the system upon changing the NtfsMftZoneReservation value is a serious drawback; the user unnecessarily loses control.

Johan

[jaclaz]

Interesting results.

Maybe defrag .
I found it "queer" that a reboot is needed/mandatory.

The $MFT zone reservation is something that make little (or no alltogether) sense in "normal" use while it may make some sense on Servers (which are exactly those that you would *never* re-boot), but - generally speaking - I would never use "make sense", "obvious" or "natural" in the same sentence with anything made by the good MS guys , it is very possible that these features (or lack of) are by design:
http://reboot.pro/3541/

jaclaz

[DiracDeBroglie]

I already did the defrag test some time ago on Win7 and WinXP as well, but no result what so ever; the new MFT settings did not take any effect after defrag on the volumes. I tested it again this afternoon on a logical volume and a primary volume under Win7; still the same result as before: new MFT settings do not take any effect. Reformatting the 2 test volumes resulted also in an MFT zone reservation according to the old MFT settings (at boot time); the new MFT setting were simply ignored. Did the whole test again by deleting the 2 test volumes and re-creating them. Again, the MFT zone reservation for the newly created volumes went according to the old MFT settings (at boot time). I really had to reboot the computer to let the new MFT setting take effect.

I was under the impression that upon reformatting a volume the new MFT settings would take effect but now it became clear to me that this is definitely not the case. (Can't remember why I was under the impression before that reformatting would take the new MFT settings.)

Anyhow, is there any Microsoft forum, website, email address, or whatever, where users could just drop/post suggestions to the developers/programmers of Win7 to improve Win7?

Johan

This post has been edited by DiracDeBroglie: 20 February 2012 - 11:06 AM

[jaclaz]

DiracDeBroglie, on 20 February 2012 - 10:56 AM, said:

I already did the defrag test some time ago on Win7 and WinXP as well, but no result what so ever; the new MFT settings did not take any effect after defrag on the volumes. I tested it again this afternoon on a logical volume and a primary volume under Win7; still the same result as before: new MFT settings do not take any effect. Reformatting the 2 test volumes resulted also in an MFT zone reservation according to the old MFT settings (at boot time); the new MFT setting were simply ignored. Did the whole test again by deleting the 2 test volumes and re-creating them. Again, the MFT zone reservation for the newly created volumes went according to the old MFT settings (at boot time). I really had to reboot the computer to let the new MFT setting take effect.

I was under the impression that upon reformatting a volume the new MFT settings would take effect but now it became clear to me that this is definitely not the case. (Can't remember why I was under the impression before that reformatting would take the new MFT settings.)

Then it is possible that the MFT settings in the Registry is ONLY read on initialization of some filesystem-related DLL.
The "final test" would be to put a "hook" on it with Regmon/procmon and create a boot-time log.

DiracDeBroglie, on 20 February 2012 - 10:56 AM, said:

Anyhow, is there any Microsoft forum, website, email address, or whatever, where users could just drop/post suggestions to the developers/programmers of Win7 to improve Win7?

Sure there are, the issue is that AFAIK :

• the product must be listed among those "open for suggestions"
  
• they won't probably ever reply to you
  
• they most probably won't even listen to your suggestion
  
• in any case, no matter how valid the suggestion will be, chances it will be actually implemented depend on "random" factors

http://connect.microsoft.com/

Good luck!

jaclaz

[DiracDeBroglie]

I've downloaded Process Monitor v2.96 from
http://technet.micro...ernals/bb896645

I installed it, and ran it, but what a huge amount of data. I've been searhing for the string NtfsMftZoneReservation but no hit. I generated a boot-time log file which is in the many GBs size. How do I proceed from here?

Johan

[jaclaz]

DiracDeBroglie, on 21 February 2012 - 10:27 AM, said:

I've downloaded Process Monitor v2.96 from
http://technet.micro...ernals/bb896645

I installed it, and ran it, but what a huge amount of data. I've been searhing for the string NtfsMftZoneReservation but no hit. I generated a boot-time log file which is in the many GBs size. How do I proceed from here?

Johan

Procmon needs some time to get familiar with.

If I were you I would try :

• removing ALL filters
  
• Add only one filter:
  

  Quote

  Path is HKLM\System\CurrentControlSet\Control\Filesystem
  
  
• Check "Drop filtered events"

jaclaz

[DiracDeBroglie]

I've done severeal tests with ProcMon, but those didn't go very well. With *Enable Boot Logging* being active, the computer freezes very often during boot, I then have to reboot for a second time, which then works fine. Very often the Logfile.PML is corrupted and I have to redo the whole thing. During normal operation, long after the computer has been rebooted, ProcMon freezes the computer; the only option is then to reboot the hard way, that is, Power off as Ctrl Alt Delete does not work. Anyhow, I managed to get several boot-time logfiles with the appropriate filters.

I did the test with 2 filters,

Filter 0:
Path = HKLM\System\CurrentControlSet\Control\Filesystem

Filter 1:
Path = HKLM\System\CurrentControlSet\Control\Filesystem
Detail = NtfsMftZoneReservation

In the boot-time log file I didn't see anything referring to the key NtfsMftZoneReservation being read [I got an screenshot but I can't insert it.]. Is there any way to pin-point ProcMon closer to the key NtfsMftZoneReservation?

Johan

[jaclaz]

DiracDeBroglie, on 23 February 2012 - 04:39 AM, said:

I've done severeal tests with ProcMon, but those didn't go very well..
......

In the boot-time log file I didn't see anything referring to the key NtfsMftZoneReservation being read [I got an screenshot but I can't insert it.]. Is there any way to pin-point ProcMon closer to the key NtfsMftZoneReservation?

HMMM.
It is also possible that something is physically written to the disk BUT read only at a reboot.

I.e. it is a three steps procedure:

• you change the setting in the Registry
  
• *something* reads this setting and writes *something* else to disk
  
• at next reboot the *something else* is read from disk and the changes are applied

I am short of ideas.

jaclaz

[DiracDeBroglie]

In Win7 the problems I experiend for the 2TB USB3 drive are exactly the same as those for the internal 1TB drive in my laptop. For both drives (internal and external) Win7 does not apply the new MFT zone reservation settings, not even when reformatting or creating whole new volumes. New MFT zone reservation settings are only applied after reboot.

I've now done the tests again on my WinXP laptop, only with the external 2TB drive, and the problems are exactly the same as under Win7. Under WinXP I did not perform the tests on my internal (boot) drive, though; this drive is filled up 95 percent and risks are too high something could go wrong with my data on that drive.

It would be nice if someone could reproduce my findings about the MFT zone reservation.

The processes that read the HKLM\System\CurrentControlSet\Control\Filesystem registry keys are FBAgent.exe, Explorer.exe, SearchProtocolHost.exe, and GoogleUpdate.exe.

Johan

[bphlpt]

So if the "problem" is exactly the same on both XP and Win7, then is it really a problem, or is it just the way it works? And why is it a problem that the new settings don't go into effect until after a reboot? This wouldn't be the only setting for which that is true.

Cheers and Regards

[jaclaz]

bphlpt, on 23 February 2012 - 06:35 PM, said:

So if the "problem" is exactly the same on both XP and Win7, then is it really a problem, or is it just the way it works?

I think that it is both.
I.e.:

• it is the way it works (no doubts after the extensive experimentations by DiracDeBroglie, though obviously an external confirmation would be nice)
  
• it is a problem as theoretically it does pose a problem

bphlpt, on 23 February 2012 - 06:35 PM, said:

And why is it a problem that the new settings don't go into effect until after a reboot?

Right now it seems like there could be an issue of this kind (IF I get it right the data till now experienced):

• a disk is mounted normally on a XP system (that has been set - senselessly - with NtfsMftZoneReservation=4)
  
• the disk is connected to a system running 7 (with a "standard" NtfsMftZoneReservation=1)
  
• a reboot on the windows 7 system is performed (if needed to "trigger" a change the behaviour of the $MFT reservation )
  
• some files are copied to the disk from the windows 7 system right after the current, "reduced size" reservation zone
  
• the disk is returned to the Windows XP system

Will it's structure be (slightly or profoundly) altered?
Will this have effects on (say) data access speed?
Will this have effects on (say) recoverability of (previously and independently or during the "windows 7 session") deleted files?
.....

The NtfsMftZoneReservation is a "system wide" setting, affecting *all* drives, if - for any reason - there is a nedd to "mantain" different disks with different MFT reservation sizes across different OS, I find inmteresting to understand if it is possibel to do so, and if not WHATwill happen when *something* is changed, and exactly WHEN it will happen ....

bphlpt, on 23 February 2012 - 06:35 PM, said:

This wouldn't be the only setting for which that is true.

Sure , but it is interesting IMHO to understand the exact way this happens.

jaclaz

[DiracDeBroglie]

I fully agree with your critical view, jaclaz. Still working on another problem now. I'll be back.
Johan

[jaclaz]

DiracDeBroglie, on 24 February 2012 - 11:54 AM, said:

Still working on another problem now. I'll be back.

No prob whatsoever.

Corollary to my previous post is that since the two different ways to set the NtfsMftZoneReservation were respectively set with Win NT 4.0 Service Pack 4 (SP4) and changed with Vista

http://technet.micro...y/cc767961.aspx
http://support.micro...;174619&sd=tech
http://www.msfn.org/...on/page__st__13
http://support.micro....com/?id=961095

and this issue was never AFAIK/AFAICR raised, I would rate the priority of the theoretical problem as extremely low.

Seemingly - and at least initially - the setting was "carved in stone" and only applied to newly created filesystems:
http://technet.micro...y/cc767961.aspx

Quote

You must change this Registry setting prior to the creation of an NTFS volume. The modification affects only those volumes created after you create this Registry entry—the modification doesn't change existing NTFS volumes, which retain their original MFT zone reservations. Also, allocating more space for the MFT won't limit the amount of free disk space available for regular file storage, because NTFS will use the MFT zone if the normal user file area becomes full.

jaclaz

This post has been edited by jaclaz: 25 February 2012 - 03:43 AM

[DiracDeBroglie]

I don't expect any *big* or *serious* problems with an MFT zone reservation that flips forth and back from large (GBs) to small (MBs) when one switches between WinXP and Win7 machines, especially when the drive is meant for data storage and not as a boot drive; MicroSoft would've detected it years ago if it were otherwise.

But anyhow, you never know that this issue may have some nasty unexpected side effects somehow. Just image, you got a dual boot system with WinXP first installed followed by a Win7 installation on another partition. After booting from Win7, Win7 can see the WinXP partition and shrinks the MFT zone to just over 200MB, from an initial size of GBs. If under a Win7 boot one then drops a file onto the WinXP partition, it may very well be that this userdata file comes right behind the 200MB MFT zone on the WinXP partition, blocking any possible expansion of the MFT zone if one boots next time into WinXP. If the user at a later time installs more apps onto the WinXP partition, no doubt that it will be more likely that the MFT will become fragmented and scattered all of the partition, leading to some WinXP performance degradation.

Also for RAIDs and NAS servers, which I have no experience with, I got a question. Imagine a home network with WinXP and Win7 machines all communicating with a RAID or NAS configuration for data storage. Are RAID and NAS servers transparent enough to let the WinXP and Win7 machines change the MFT zone reservations on the drives in the servers? If yes, one second a WinXP machine creates a large MFT zone when accessing the server, a fraction of a second later the MFT zone gets shrunk to just 200MB when an Win7 machine gets access. A process like that could flip-flop the MFT zone forth and back in size many times per minute until there is enough data on the drive to encapsulated the smallest MFT zone reservation (200MB). I'm not sure if this could happen, it is just that in a year or 2 I may consider purchasing a RAID or NAS configuration.

BTW. I just tried *fsutil behavior set mftzone <n>* in an elevated cmd promp in Win7. It works, but I got a message saying the new setting requires a reboot to take effect. In WinXP the command works as well but does not give a notification to reboot, although a reboot is required in WinXP too. Note that in WinXP the fsutil command does not appear in the command list after typing help in the prompt. It really makes me wonder about the usefulness and the effectiveness of the possibility to change the MFT Zone Reservation, especially with servers that never reboot (as mentioned earlier by jaclaz).

Johan