Intro Download and install Frequently Asked Questions Tips and tricks

Homepage







© J.C. Kessels 2009
MyDefrag Forum
October 30, 2014, 06:27:11 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: MFT Calculations  (Read 7451 times)
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« on: March 03, 2009, 04:48:17 pm »

While fiddling around with MFT defragmentation I recognised that MyDefrag refuses to move the MFT to the very beginning of my disk. Also the diskmap shows that part as belonging to the MFT reserved area. Doing a -d 3 run the log shows the following:
Quote
15:27:26       Mft reserved area 1: from 3879134 to 3911482 (32348 clusters).
15:27:26       Mft reserved area 2: from 64672 to 93664 (28992 clusters).
15:27:26       Mft reserved area 3: from 16 to 32364 (32348 clusters).
But windows happily places data into the area shown as "Mft reserved area 3" while having plenty of regular free space so this area does not seem to be "reserved" at all. Looking at the V3 Sources it seems that this "Mft reserved area 3" stems from the calculation of the MFT Mirror size being the same as the MFT size. However, $MFTMIRR is way smaller. Please find more information here: http://technet.microsoft.com/en-us/library/cc781134.aspx. The important part states as follows:
Quote
The $MftMirr is a duplicate image of either the first four records of the $Mft or the first cluster of the $Mft, whichever is larger.
So in general it will be only 4KiB in size.

Just came across this and thought it worth dropping a note.

regards
gerd
Logged
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7233



View Profile WWW
« Reply #1 on: March 05, 2009, 07:49:30 pm »

Thanks for the feedback, I appreciate it! I've learned only a few weeks ago that the meaning of the reserved areas has changed and I have been meaning to look into it, but haven't yet have time for it.
Logged
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« Reply #2 on: March 05, 2009, 10:42:36 pm »

The only change needed is the calculation of MftExcludes[2].End to be only 4KiB or 1 Cluster behind Start. I modified a 3.36 that way and activated the MFT moving routines and it made a perfectly aligned MFT.

Btw. I noticed that the MFT itself is also moved outside the reserved area. I know that the API refuses to move regular files into the reserved Area, does this also apply for the MFT? It seems a bit useless to have the MFT split by the reserved area...

I forgot to mention: I'm running XP, not vista.
« Last Edit: March 05, 2009, 10:45:45 pm by gerdb » Logged
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7233



View Profile WWW
« Reply #3 on: March 11, 2009, 01:22:19 am »

Thanks for sharing your observations. I have made a note and it will help me when I have time to look at it.
Logged
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« Reply #4 on: March 27, 2009, 12:41:21 pm »

Did some more fiddling (different drive than before) and came to one more point:

This is what MyDefrag shows:
Quote
10:40:53       Mft reserved area 1: from 786432 to 852912 (66480 clusters).
10:40:53       Mft reserved area 2: from 83520 to 242464 (158944 clusters).
10:40:53       Mft reserved area 3: from 16 to 66496 (66480 clusters).
However, FSCTL_GET_NTFS_VOLUME_DATA reports the following (taken from Debugger):
Quote
+      MftValidDataLength   {272302080}   _LARGE_INTEGER
+      MftStartLcn   {786432}   _LARGE_INTEGER
+      Mft2StartLcn   {16}   _LARGE_INTEGER
+      MftZoneStart   {83520}   _LARGE_INTEGER
+      MftZoneEnd   {242464}   _LARGE_INTEGER
So how does that fit together? Area 1 seems to correspond to MftStartLcn and has the size of the entire MFT. This would make sense if the MFT was always in one fragment. But actually MftStartLcn only marks the location of the first cluster(s) of the MFT which are unmovable. The rest of the MFT may be scattered across the entire disk (unless you use MyDefrag of course Smiley). The file system treats this as normal disk space, so there's no need for MyDefrag to keep this area clear. I think this area should match only the unmovable part of the MFT, which is 16KiB in size (or one cluster, whichever is larger).

Area 2 indeed matches the MftZone as reported by the filesystem.

Area 3 was already covered by previous posts in this thread.

Since areas 1+3 may sum up to notable amounts (more than .5GiB in my case), I'd be happy to see MyDefrag fill that space.
Logged
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7233



View Profile WWW
« Reply #5 on: March 27, 2009, 01:02:59 pm »

there's no need for MyDefrag to keep this area clear.
Interesting idea, I have made a note and will look at it later.
Logged
DWalker59
JkDefrag Hero
*****
Posts: 62


View Profile
« Reply #6 on: June 29, 2009, 02:15:32 am »

As I posted in another thread, I think the $mft and the $bitmap and maybe the $logfile each have an NTFS reserved area after them.
Logged
boco
JkDefrag Hero
*****
Posts: 153



View Profile
« Reply #7 on: June 29, 2009, 03:50:57 pm »

Quote
I modified a 3.36 that way and activated the MFT moving routines and it made a perfectly aligned MFT.
Mind sharing that?  Cool
Logged

T  hi s    Sign  a tu  re   is  q   uit  e   sor   te d  -op tim i zed  b  y desi  gn   .
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7233



View Profile WWW
« Reply #8 on: June 29, 2009, 07:54:33 pm »

Mind sharing that?  Cool
Look in the source code for a subroutine called MoveMftToBeginOfDisk(). I don't remember exactly why I disabled it, but I'm sure I had a very good reason.
Logged
Leolo
JkDefrag Hero
*****
Posts: 98


View Profile
« Reply #9 on: June 29, 2009, 11:34:00 pm »

Look in the source code for a subroutine called MoveMftToBeginOfDisk(). I don't remember exactly why I disabled it, but I'm sure I had a very good reason.

Unfortunately, the link has gone the way of the dodo:
http://www.microsoft.com/whdc/system/winpreinst/ntfs-preinstall.mspx

But the most important quote I could get from it at the time was this one:
Quote
In Windows 2000 and earlier versions of Windows NT, the MFT was typically placed at the start of the disk space available to the file system. In Windows XP, the NTFS format utilities place the MFT 3 GB further into the disk space, which has been found to improve system performance by 5 to 10 percent.

This was discussed in this forum:
http://www.kessels.com/forum/index.php?topic=321.0

Regards.
Logged
boco
JkDefrag Hero
*****
Posts: 153



View Profile
« Reply #10 on: June 30, 2009, 10:08:24 pm »

Mind sharing that?  Cool
Look in the source code for a subroutine called MoveMftToBeginOfDisk(). I don't remember exactly why I disabled it, but I'm sure I had a very good reason.
Yeah, right, but I would like to avoid compiling, my last experiment in that regard was disastrous. Wanted an executable for that reason.
Logged

T  hi s    Sign  a tu  re   is  q   uit  e   sor   te d  -op tim i zed  b  y desi  gn   .
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« Reply #11 on: July 02, 2009, 01:09:40 pm »

Mind sharing that?  Cool
Look in the source code for a subroutine called MoveMftToBeginOfDisk(). I don't remember exactly why I disabled it, but I'm sure I had a very good reason.
I recognized this to be meant "experimental" and that's why I only used it for some proof-of-concept measures. The more important change was to limit MftExcludes[0].End and MftExcludes[2].End to be only 4 (or 1 respectively) clusters after Start. And the API happily moves files into these "reserved" areas.
Logged
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« Reply #12 on: July 02, 2009, 01:24:47 pm »

Yeah, right, but I would like to avoid compiling, my last experiment in that regard was disastrous. Wanted an executable for that reason.
MyDefrag does a way better job than JkDefrag ever did even with my patches so this would be only of academic interest. And I didn't test it thoroughly enough to allow for a binary release. So I'd like to ask you to be patient and wait for a MyDefrag release addressing this.
Logged
gerdb
JkDefrag Hero
*****
Posts: 70


View Profile
« Reply #13 on: July 02, 2009, 01:59:26 pm »

As I posted in another thread, I think the $mft and the $bitmap and maybe the $logfile each have an NTFS reserved area after them.
I guess you are referring to this thread. There, I already stated why reserved areas to $bitmap and $logfile don't make sense and thus I doubt they are there. And according to HDView, on my C: partition, there is a file immediately following $bitmap and this partition never was even close to be full. So I'll take this as proof that the NTFS driver does not reserve any space after $bitmap.
Logged
DWalker59
JkDefrag Hero
*****
Posts: 62


View Profile
« Reply #14 on: July 03, 2009, 08:10:07 pm »

"thus I doubt they are there".  Hmmm.  I always see areas marked as "NTFS Reserved Area" after each of $logfile and $bitmap.  My C drive currently has the $mft near the beginning of the disk, but the $logfile and the $bitmap are in the center (after a bunch of free space)... and there's a huge dark blue 12.5% space that MyDefrag labels "NTFS Reserved Area" right after the $bitmap.  And I have rebooted, so the NTFS file system should re-mount the disk and recalculate the "NTFS Reserved Area".  Weird.

Maybe this "NTFS reserved area" is still reserved FOR the $mft, even though it is very far away from the $mft and there's about 30 or 40 GB of free space in the interval.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!