321 replies to this topic

[sfinktah]

Well, apparently I have one machine here that supports all the Intel CPU requirements to run Hyper-V.



Unfortunately, all the magic power is packed into a machine that will simply never run Windows 2008 x64. (It's an EFI thing).

It's my bloody Mac Book Pro laptop.

[sfinktah]

Before using VHD Resizer or VHD Tool to shrink a VHD, one must manually shrink its volume in Diskpart or such (that may require defrag as well, so be it).

BUT, VHD Resizer then creates a copy of VHD file of smaller or larger size, while VHD Tool doesn't - instead it changes the file size of the original VHD instantly without making its copy (possibly by updating its MFT record). There is no need to use any other utilities including WIM in this case.
Before using VHD Resizer or VHD Tool to shrink a VHD, one must manually shrink its volume in Diskpart or such (that may require defrag as well, so be it).

BUT, VHD Resizer then creates a copy of VHD file of smaller or larger size, while VHD Tool doesn't - instead it changes the file size of the original VHD instantly without making its copy (possibly by updating its MFT record). There is no need to use any other utilities including WIM in this case.

As Microsoft kindly point out, no matter what [Microsoft] tool you use to access VHDs, they all end up using the same WIN32 API. And that API is what I have access to. It can perform both kinds of compaction, I pasted the technical details of the two types of compaction on the previous page. So yes, I can perform such an compression without copying the VHD.

I just don't think it's terribly powerful. Defragmentation (even O&O Defrag, which is miles ahead of Microsoft's defrag) won't move the reserved MFT section on your drive, and the last time I tried to reduce a VHD, that MFT was the only thing in the last 10 GB of disk. Only Acronis Disk Director's Resize Partition was willing to do the dirty work.

While I certainly have no problem issuing a few trivial calls to the API to do the "by the book" compaction, it's not going to be nearly as impressive as rewriting the filesystem from scratch. And if that can be achieved using calls to a standard WIM API (I don't even know that one exists), it should be a reasonably safe and easy thing to do.

The API will also compact Differencing VHDs, BTW.

I actually have an idea about your differencing chains too... it shouldn't be too hard to analyse the entire chain, and determine what blocks are "shared" by the various differencing VHDs. Thus, if you decided to "merge" several differencing VHDs in your chain, and optimum result could be achieved by cancelling out duplicate blocks.

[sambul61]

PerfectDisk can move MFT if a disk is marked for Boot Time Defragmentation by a method selected by user (i.e. Consolidate Free Space).

It appears, you're thinking now of Compaction feature. I was talking about Resize VHD File feature, which is totally different. For that feature it makes sense to study how open source VHD Tool extends a fixed VHD without copying it. May be someone familiar with NTFS can look at VHD Tool source code and make some suggestions, how to interpret it and use to shrink a fixed VHD file if its content volume is smaller than the file. For dynamic VHDs it appears to be "footer only" task - to change max set size, so no MFT update required.

Talking of compacting and resizing, since they often complement each other, it makes sense to prepare a list of common scenarios when resizing is needed (disk type, volume-to-disk ratio, volume fragmentation), and target each task on that list by a common or unique approach. For some tasks WIM approach would work well (also depends at what stage optimization is done - capture or apply, and may require both), for others don't (i.e. you can't use it in WinXP VHDs) or be lengthy and less efficient. Compacting Diff VHDs may increase their size in some cases, web reports say.

Don't forget, to see effect of compacting, your VHD needs to be old enough to accumulate empty spaces from apps install & uninstall and such. If you just created a VHD, there isn't much to compact on it, hence a standard technique may appear unimpressive. It looks like manipulating VHDs involves quite a bit of complex tasks and scenarios. But, I'd suggest you set aside these advanced topics, and concentrate for now on GUI and implementing basic features available through VHD API.

[sfinktah]

I actually haven't touched the API yet. I'm directly accessing the VHD files on disk, since it gives me complete access to all the meta-data. I didn't realise VHD Tool was open source, or I would have paid more attention to it.

When I think about resizing I also think about compaction... They're no so much different things, as different levels of the same thing.

Don't worry about my test VHD being old enough to accumulate empty spaces.... I have some really old and fat XP SP2 VMDKs that haven't seen a defrag in 5 years.

Now technically, you're not allowed to shrink a fixed size VHD. You certainly can't do it via the windows API. The main reason for that, is that fixed size VHDs don't have a list of which chunks of disk have been used. So the VHD API would have to understand the underlying file system to know how much free space there was.

However, if it's a single partition drive, or you're shrinking the last partition, it's really quite trivial to read the partition sizes from the first 512 bytes of the file, truncate the excess data, and write an updated 256 byte VHD footer at the end.

There's already a Microsoft CLI example that implements the VHD API - although not the good bits:


CppVhdAPI.exe -[cxaomdgpe] -f <vhdfile> -s <size>
-c CreateVirtualDisk............input: -f <vhd file name>, -s <size in MB>
-a AttachVirtualDisk............input: -f <vhd file name>
-d DetachVirtualDisk............input: -f <vhd file name>
-g GetVirtualDiskInformation....input: -f <vhd file name>
-p GetVirtualDiskPhysicalPath...input: -f <vhd file name> -- note: must be attached
-e SetVirtualDiskInformation....input: -f <vhd file name>, -u <new GUID>

And here's someone GUI version of the same, equally pointless code.




But remember, shrinking the size of fixed VHDs will have to be done totally outside of the API, where-as shrinking or compacting of dynamic or differencing VHDs is done with-in the API.

I'm following up the non-API methods first, since there are already ways to do things the traditional way. I think it will show more impressive results sooner... and it's also very educational. Far better to know exactly how a VHD works before trying to get things done via an API that hides everything.

And it's not nearly as hard as you might think.

[sambul61]

shrinking the size of fixed VHDs will have to be done totally outside of the API, where-as shrinking or compacting of dynamic or differencing VHDs is done with-in the API.

Not exactly... Shrinking a dynamic VHD means decreasing its max set size, which is impossible via API. Compacting is possible, but does nothing to make the VHD occupy less space after OS boots from it. Also, for fixed VHDs, some free space must still be left in the volume upon trimming the file.

[sfinktah]

You're right... I had to re-read the API to believe it though, as it sounded counter-intuitive. But it does make sense, since shrinking a dynamic VHD would involve shrinking the partition, which is outside the scope of VHD operations.

Still, it's certainly easy enough to do in code, but it would be a "perform at own risk" operation. You can nominate any size you like, and I'll have the code adjust the partition table and the VHD... but if you accidentally truncate data, or (more likely) MFT reserved sectors, the results would be "undefined."

That could be fixed in a later release of VHD DIrector though, since it's only a matter of checking the allocation table at the start of the VHD to check where the last used "sector" is.

[sambul61]

From a dynamic VHD definition in the VHD spec it appears that its partition size always corresponds to amount of data on it, and has nothing to do with its max set size. Hence, at first look changing its max size doesn't involve shrinking its partition, but it depends how partitions and volumes are defined in a dynamic virtual disk. Its unclear if there is any commonality with regular NTFS Dynamic Disks... Interesting, how many cross-discipline issues are involved in managing VHDs, and their control requires digging deeper and deeper into this matter.

[sfinktah]

I believe that "interesting cross discipline" factor is why the specification draws the line strictly at saying "This is a disk, we don't know what's on it, but here it is."

I did some research on it, and it turns out that Connectix originally developed the VHD format for Macintosh. So they have a good excuse for being agnostic about the contents.

What VHD specs are you reading that talk about partitions?

Latest (very small addition) to VHD Director, I have added the Dynamic Disk Header (where appropriate) to the output. Not terribly impressive, I know, but it's strictly a "block by block" operation at the moment. The lists aren't going to stay read-only, I'll be making them fully editable. Imagine what you see here as the left hand side of regedit, and on the right hand side, there will be a description of the field, appropriate calculation functions, maybe automatic adjustment buttons, instructions, and maybe even pretty pictures.

Each field would have it's own custom editing panel (where appropriate), or a very boring regedit style edit box if the field is of no interest.



Next up in the "block by block" sequence:

Block Allocation Table and Data Blocks

(Strictly speaking, that's two blocks... but they're simple blocks, and will produce nice graphical output of disk usage). After that's out of the way, then it's my favourite block of all.

The Master Boot Record.

At that point, I'll start by attaching of the VHD for user to manipulate (shrink) partitions, then making the necessary adjustments to the VHD to shrink it to match.

How does that sound?

[sambul61]

Given cross-discipline nature of the task, you're doing very well. I'd still suggest to master and display Basic VHD API commands before going too far south.

I'd suggest to offer 2 GUI modes:

- Basic (for mass user) would show no editable or read-only disk header & footer or other fields, but only buttons for automated operations and input fields for desired by user values (like disk size or pass);
- Advanced (for IT Pros) would look more like you described, giving more flexibility in adjusting the output, assuming an IT Pro knows a bit about what he's doing.

Regarding VHD Spec, while it was developed by Connectix, it was adapted by MS to their NTFS scheme, and this is MS VHD Spec you linked earlier. Hence, it looks like a Fixed VHD is analog of Basic Disk, and Dynamic & Differencing VHDs are analogs of Dynamic NTFS disks. Otherwise how would they operate in NTFS environment, especially when booted from? That means, a Dynamic VHD has a single dynamic physical partition that spans to its max size when booted from. It may have several simple or dynamic logical volumes inside that partition. A volume spans to the size of data on it at any time, and can eventually match the size of underlying partition, as data grows. One can assume (and its easy to find out), a dynamic VHD file can span over several physical disks, when created on a Dynamic Drive, or over a single disk if placed on a Basic Drive. But its OS volume must be on a single drive. A differencing VHD is also a dynamic VHD with a single dynamic partition and single dynamic volume, and contains data sectors "delta" from its Base, while a Dynamic VHD contains all data sectors in itself.

From that view, shrinking max set size of a dynamic VHD file entails shrinking its partition, and may also entail defragging, compacting and shrinking its volume, if its large enough and close to max set disk size. It appears, auto adjusting volume size is native feature of Dynamic VHDs.

[sfinktah]

Sorry to say that Hyper-V won't run on your processor, since it doesn't support VT-d and Trusted Execution (DEP), and neither in any popular VM, but will run VMs when started from a native boot VHD on supported HW. I suggest to install Win7 Virtual PC SP1 for your Win7 platform (i.e. 64-bit, it doesn't require VT & DEP) and do all testing in it or on real HW.

I think you have that a bit backwards, Hyper-V specifically won't run on system with VT-d OR Trusted Execution enabled.

The two extensions it does require:

Hardware Virtualization Assists* in the form of:

• Intel VT-x (initially codenamed Vanderpool)
• AMD AMD-V (also called SVM and initially codename Pacifica)

Hardware Data Execution Prevention:

• Intel refers to it as Execute Disable (XD). This feature must be enabled in the system BIOS.
• AMD refers to it as No Execute (NX). This feature must be enabled in the system BIOS.

Note that Trusted Execution Technology = TXT, not DEP. Intel's rendition of DEP is the Intel Execute Disable Bit.

Intel® Core™ i7-2600K Processor
(8M Cache, 3.40 GHz)

[sfinktah]

a Fixed VHD is analog of Basic Disk...

Sorry, going to have to disagree on everything starting from that sentence.

a VHD is a non-physical container that represents a physical disk, nothing more. It has no ties to NTFS, or any principle of NTFS.

Here is a ZIP of a VHD I just created by formatted an empty disk with DISKMGMT in WIndows 7, and imaged with DISK2VHD.

Please download it and verify for yourself that it has no MBR or MBR partition table, and contains no NTFS partitions, yet mounts a perfectly functional 400 MB drive. You can even attempt to extend it's size.

http://nt4.com/FAT32-GPT.VHD.zip - 13K

Disk geometry: 833/16/63 [839680 sectors]

Signature: 0xAA55

		 Starting	   Ending

#: id  cyl  hd sec -  cyl  hd sec [	 start -	   size]

------------------------------------------------------------------------

1: EE	0   0   2 - 1023 255  63 [		 1 -		 -1] <Unknown ID>

2: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused	

3: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused	

4: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused	

MEDIA: ""; Size 410 MB (839680 x 512); Max Transfer Blocks 2048

SCHEME: 1 GPT, "GPT Partition Scheme" [16]

SECTION: 1 Type:'MAP'; Size 410 MB; Offset: 34 - 839647, (839613 x 512)

ID Type				 Offset	   Size		 End		  Name					  (1)

-- -------------------- ------------ ------------ ------------ -------------------- --------

   Free						   34		65630		65663

2 Microsoft Basic Data		65664	   770048	   835711 Basic data partition

   Free					   835712		 3935	   839646

	   	 partition-UUID: 6518A173-B55C-4495-A1DB-BC570BBEF78C

			partition-name: Basic data partition

			partition-hint-UUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

			partition-start: 65664

			partition-number: 2

			partition-length: 770048

			partition-hint: DOS_FAT_32

			partition-filesystems:

				FAT32: FAT32EFI

Edited by sfinktah, 26 November 2011 - 06:44 PM.

[sambul61]

Yes, VHD is a container. More, this utility raw2vhd allows to transform IMG container to VHD by adding a specific VHD footer. However, the volume inside VHD is formatted in NTFS (talking of native boot Win7 VHDs), and preserving integrity of that file system is crusial for booting OS from the VHD.

Once you mount a VHD, open Disk Management and see if it has any partitions & volumes inside? Open any other disk partitioning or defrag tool and look again, how the disk data is represented in its GUI. One can't boot Windows from a NTFS partitioned volume placed on a VHD, unless that volume is interpreted the same way it was created - as NTFS partition. Don't forget (and possibly try yourself) to boot WinXP from VHD - there are Tutorials on this forum teaching how to do just that, and they all include formatting the VHD as NTFS drive. One might not need MBR to boot from it, since MBR is added to the host system drive, but a boot sector and/or other boot related files may need to be on the VHD volume to boot OS from it.

However, when trying to manipulate & shrink an offline detached VHD (i.e. a file non-interpreted by NTFS as a volume), there might be various techniques used to do that, provided the result would allow NTFS to interpret and mount the volume properly with all data preserved and accessible. I.e. formatted volume structure on the VHD must be preserved or updated when shrinking it. Some try-and-learn work required to achieve this, given not much info on the subject disclosed anywhere.

Before telling, what I get wrong about Hyper-V hardware requirements, try follow the links provided and the links on the subject provided on the linked pages. Both features I mentioned (VT and DEP) must be supported by your proc and switched ON (meaning virtualization and prevention). I don't need any arguments, since found long ago what Hyper-V and VHD need to run. But thanks anyway, and may be someone will get interested in your fresh look, presumably tested one.

[sfinktah]

Sorry, but I don't believe VHDs need boot sectors to run. The boot sector loads bootmgr, which loads the BCD which presents you with a list of things to boot. From that list you then pick the VHD.

Ergo, the boot sector need not be on the VHD, and although I haven't specifically checked sector 0 on my VHDs for boot sectors, I know that there is no boot directory.

With regard Hyper-V, your revised statement is correct, your original one was not.

[sambul61]

Sorry, but I don't believe VHDs need boot sectors to run... I know that there is no boot directory.

Are you familiar with Grub4DOS? One can boot a VHD by selecting its entry in Grub4DOS (or similar bootloader) Menu, if suitable boot environment was added to the OS volume on the VHD. In fact, its the only way to boot WinXP VHD with WinVBlock or FiraDisk (or similar virtual disk driver) installed to it.

Intel's rendition of DEP is the Intel Execute Disable Bit.

Just wanted to help, since you couldn't install Hyper-V, otherwise don't care how various chip makers name similar features: this is your proc, and therefore your problem.

[sfinktah]

Are you familiar with Grub4DOS? ../public/style_emoticons/default/smile.png One can boot a VHD by selecting its entry in Grub4DOS (or similar bootloader) Menu, if suitable boot environment was added to the OS volume on the VHD. In fact, its the only way to boot WinXP VHD with WinVBlock or FiraDisk (or similar VHD driver) installed to it.

Ahhh, I haven't had the joy of doing a grldr for a vhd, i was curious how it was done. certainly didn't know it could map vhd files (although i guess it could treat fixed size vhd as a raw image without much harm).

actually i think booting into multiple vhds from windows is about the only configuration in which you can get away with not having a boot environment.... probably 90% of vhd usage in virtual machines, and iscsi storage. both of which are going to need boot stuff (if they're boot drives).

reminds me of an idea .... which is unfortunately beyond my programming skills...

an intelligent boot loader (i cringe from using the word "universal").

i.e. booting windows without using a BCD and just having it detect the installed windows, maybe scan for VHD files in root directory, maybe even iscsi or usb... *sigh*

what does bootmgr actually do after it reads a bcd anyway? in the old days, i guess NTOSKRNL (sp?) was loaded by ntldr (correct me if i'm missing a step)... but what does bootmgr do? and what does it do that's so special, you have to using the "latest" bootmgr (e.g. in vista & seven dual boot).

something based on chameleon, but smarter.

Edited by sfinktah, 27 November 2011 - 07:58 AM.

[sfinktah]

• Added Visual Display of Allocate Space in Dynamic VHDs.



The extremely wide screen-shot was necessary to capture the small unused spaced. Source VHD is: http://www.microsoft...s.aspx?id=11575

[sambul61]

what does bootmgr actually do after it reads a bcd anyway?

Bootmgr loads winload.exe from the system volume specified in BCD upon selecting by a user the OS version to boot in Boot Menu. If the system volume is inside a VHD file (as pointed in BCD), Bootmgr seems to mount the VHD file as NTFS volume in real mode supported by BIOS, so it becomes accessible to load winload.exe from it, which continues boot process from the volume, including loading direct hardware access drivers like a VHD driver, which re-mounts the VHD disk and allows to continue boot process in Windows protected mode. Of course, its only possible if that NTFS partition and system volume on it inside the VHD weren't damaged by directly editing VHD file in 3rd party tools.

Test booting Win7 from VHD (unsupported for native boot versions) with Grub4DOS is shown here:

Command root (hd0,0) transfers boot focus to drive 0 & partition 0, which is the 1st partition on a fixed active bootable system VHD disk mounted at that point in real mode by Grub4DOS, with its partition table recognized and File System read. Then control is transfered to chainloader /BOOTMGR. Instead, one can use command chainloader (hd0)+1 to transfer control to MBR of the VHD disk, or chainloader (hd0,0)+1 to transfer control to PBR on its 1st partition. Bootmgr starts winload.exe (no need to mount the VHD, since its already mounted), WinVBlock is loaded and mounts the VHD in protected mode as a file backed disk, thus replacing inactive native Win7 VHD driver. MBR and PBR can be added to a VHD with bootsect command run from Command Prompt as per this Tutorial that you claimed to have read, and even duplicate with MS video .

actually i think booting into multiple vhds from windows is about the only configuration in which you can get away with not having a boot environment (inside VHD)

And it doesn't change a thing, since the task is not to mount a VHD (like in your "empty file" example) in running OS after shrinking, but to boot OS from it. Bootmgr would still need to mount a pointed in BCD VHD file in real mode as NTFS volume, and start winload.exe from it...etc...so that finally it can appear to a user as NTFS system volume upon boot. Which means, the volume inside VHD must be in good standing and proper spirit.

[sambul61]

Multibooters site provides wealth of info about the boot process. See also All about MBR and OS Boot Records and NTFS.


"The bootmgr consults the BCD file for the information it needs to find the correct drive and partition, but it does not use the firmware to find the hard drive, or the partition table to find the partition. Instead it uses the unique Disk Signature in the MBR of a hard drive and the partition offset (starting sector) of a partition.

Inside the BCD store each boot item is in its own little container (Object) and many of these Objects hold details of the disk signature of the hard drive and the starting sector of the partition where the item to be started is located. Each Object is labeled with a 32 digit alpha/numeric number called a GUID number. When bootmgr is asked to start a boot item it identifies the item's Object by its GUID number and then reads the disk signature and partition offset information that is contained in that Object. Bootmgr then scans the connected hard drives until it finds the drive with that disk signature and then jumps straight to the desired sector on that hard drive by using the partition offset information."

So, in case of booting unsupported Win7 from VHD with Grub4DOS, Bootmgr must be inside a mounted VHD volume, and because of that it must look in MBR for the right drive to boot by disk Signature derived from BCD entry inside that volume, rather than using a pass to VHD file given by BCD in case of booting a VHD from Host Boot Menu. Hence, the VHD must have MBR in this case, and the actual partition offset must match BCD data.

In case of booting WinXP from VHD with Grub4DOS, ntldr must be inside the VHD volume, and it looks in Boot.ini on the same VHD volume what OS to boot, then proceeds with booting it. Hence, the VHD doesn't need MBR in this case, but again it may have proper MBR and PBR, and Grub4DOS will chainload any of these. Grub 4DOS Menu section will look similar for booting both WinXP or Win7 from VHD, but used virtual disk driver must support booted OS from VHD.

--------------------------------------------------------------

So, we're back to a more unified approach to resizing a VHD, based on preserving data and structure integrity in and out of it. And the right 1st step in making your app work IMHO is implementing existing VHD API via Program GUI and shell commands similar to ImDisk driver: it has a Control Panel applet and Shell commands selectable from mice RMC. Once you overcome this stage and have a stable app with attractive GUI, you may look at adding more complex staff to it and doing more testing. Again, ImDisk developer shown in his section on this forum, advanced knowledge and experience may be required to accomplish some tasks, and you'll gain it as you go. Just look at VHD Tool code - it does CREATE and EXTEND fixed VHD commands by disregarding data on affected sectors, because its a low intelligence tool, and it relies on human intelligence instead - its one possible way, there may be other. Plus, you need a list of shrinking scenarios.

Take example from MS - they do all development work based on carefully sorted list of typical usage scenarios in select markets.

[sfinktah]

Will read over your posts presently, just stopped into paste this interesting analysis from O&O Defrag.

I'm currently running one of those pre-built VHDs that Microsoft is giving away at the moment, this one is the Windows 7 IE9 test platform. I am running it in VMware, but I attached the original VHD to see if I could move the MFT on a non-boot drive.

The funny thing was...



There is no MFT reserved space on either the running VMDK, or the mounted VHD. Have you ever seen something like this before? I've never tried to defrag a VHD I made from scratch, so it might be common... What do you think?

I should add, that it isn't a boot volume. There is a 100 mb boot partition, which does has a MFT reserved slab. Perhaps only the boot drive is required to have such this. If so, much better it be 12-20% of a 100mb boot volume than 12-20% of a 120 GB dynamic VHD. (Which is what this is).

Edited by sfinktah, 28 November 2011 - 01:12 PM.

[sambul61]

It's normal, since reserved MFT would increase download size. In fact, I don't remember exactly, but after applying Win7 to a new drive there might be no MFT reserved space either. Once you defrag the disk, it should show up. Another thing is, my running Win7 don't show either any MFT reserved space in defrag soft (may be it's hidden or absent), but when the same volume is looked at from another running OS, it may show MFT right away or after defrag depending on the host OS version. What's your VMWare and its host's OS versions? I'd use Win7 Virtual PC for cleaner results anyway, but are you running it on Mac - I sense from your arguments, you don't normally use NTFS?

It makes sense to look on the web, if there is a way now to switch Off MFT space reservation in running Win7, but the issue is also relevant to Pagefile.sys - this one you can switch Off, though Hiberfil.sys shouldn't be there in VHD.

[Wonko the Sane]

JFYI :
http://www.mydefrag....msg6524#msg6524


Wonko

[sambul61]

Interesting, what's the default MFT zone size for Win7 64-bit? OK, I got it: calculated by OS, and changeable up or down to default by running Fsutil, but a lot smaller than 12.5% in Win2000/XP. The above MFT restriction method should be tried in Win7 too to block it from moving MFT zone to free space at the drive's end, since it prevents VHD shrinking. But might result in Zone grows & fragmentation upon next defrag, especially if not a boot time defrag - depends on the defrag package used.

There is apparently a Registry key NtfsMftZoneReservation in HKEY_LOCAL_MACHINESystemCurrentControlSetControlFileSystem to extend its size (values 1 to 4, i.e. 200, 400, 600, 800 MB - pretty small given today's disk sizes), but not below the default value (which corresponds to 0 value in Win7 Registry, i.e. MFT zone size controlled by OS).

The default MFT Zone is calculated and reserved by Ntfs.sys when it mounts the volume. It explains, why the same volume has a different size MFT zone, when mounted from a different running OS version. I noticed, once MFT zone is increased in one OS, it may or may not shrink automatically after switching to another OS.

[Wonko the Sane]

Read this one:
http://ss64.com/nt/fsutil.html
try doing a couple experiments....


Wonko

[sambul61]

I guess, MFT zone grows is more often caused by a defrag app rather than system needs... But it sounds strange, since defrag soft decreases number of file fragments - so anyone knows why is that? Any links explaining this phenomenon - its typical for many defrag packages, but at times interpreted as a certain package bug?

[Wonko the Sane]

JFYI:
http://www.diskeeper.com/blog/post/2006/11/07/The-Mystery-of-the-Disappearing-MFT-Reserved-Zone!.aspx
Besides the article itself, the MS document linked in it, which you can find through the Wayback Machine here:
http://web.archive.o...45/2kuptoXP.doc
has some not-so-known info.

The "KB that started it all" has still some meaningful info:
http://support.micro...kb/174619/en-us


Wonko