DiracDeBroglie

$MFT zone reservation; glitches?

18 posts in this topic

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.sourceforge.net/en/index.html

http://sourceforge.net/projects/ultradefrag/files/stable-release/5.0.2/

Edited by DiracDeBroglie
0

Share this post


Link to post
Share on other sites

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. :unsure:

Tools mentioned here may come handy:

http://reboot.pro/15086/page__st__25

jaclaz

0

Share this post


Link to post
Share on other sites

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

Johan

Edited by DiracDeBroglie
0

Share this post


Link to post
Share on other sites

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

Johan

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

  1. CHKDSK
  2. CHKDSK /F
  3. 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 :unsure: 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

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

Interesting results. :thumbup

Maybe defrag :unsure:.

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

0

Share this post


Link to post
Share on other sites

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

Edited by DiracDeBroglie
0

Share this post


Link to post
Share on other sites

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. :unsure:

The "final test" would be to put a "hook" on it with Regmon/procmon and create a boot-time log.

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 :

  1. the product must be listed among those "open for suggestions"
  2. they won't probably ever reply to you
  3. they most probably won't even listen to your suggestion
  4. 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

0

Share this post


Link to post
Share on other sites

I've downloaded Process Monitor v2.96 from

http://technet.microsoft.com/en-us/sysinternals/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. :ph34r:

If I were you I would try :unsure::

  1. removing ALL filters
  2. Add only one filter:
    Path is HKLM\System\CurrentControlSet\Control\Filesystem
  3. Check "Drop filtered events"

jaclaz

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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. :unsure:

I.e. it is a three steps procedure:

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

I am short of ideas. :(

jaclaz

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.:

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

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):

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

Will it's structure be (slightly or profoundly) altered? :w00t:

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 ....

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

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.