Condusiv Technologies Blog

Condusiv Technologies Blog

Blogging @Condusiv

The Condusiv blog shares insight into the issues surrounding system and application performance—and how I/O optimization software is breaking new ground in solving those issues.

Diskeeper x(4 score bits minus 2 bytes)

by Michael 21. November 2006 02:49
One of the frequent questions our staff are asked is whether Diskeeper for Windows x64 operating systems (AMD64/EM64T - CPUs) is native or compatible? By compatible, that of course means it runs in 32 bit mode; native referring to it running in 64 bit mode. Beginning with Diskeeper 10, the Professional editions (and above) have operated entirely in 64 bit mode. We recompiled the software and made the necessary edits to offer this to users running x64 operating systems. While unexpected, we did see some slight performance gains. One of the perks of x64 architecture, as noted in wikipedia.com's x86-64 entry is: "very large files can be operated on by mapping the entire file into the process's address space (which is generally faster than working with file read/write calls), rather than having to map regions of the file into and out of the address space." If you're a avid video editor or engineer working with CAD/CAM 4GB+ files (not uncommon these days), you've likely been running Windows XP x64 for some time. As Diskeeper 10 had a multiple component architecture, both the scheduling service (dkservice.exe) and the defragmentation engines (DfrgNTFS.exe and DfrgFAT.exe) ran in native 64 bit mode. In Diskeeper 2007 all operations are controlled directly under the Diskeeper Service (still called DKService.exe), and it too runs native x64. When you download and extract the purchased software you'll notice right away that you receive two instances of Diskeeper. One installation program is for x86 and the other for x64. Each comes in an independently labeled folder. An autorun.exe program will properly select the install file to execute. If you have an x64 processor but a 32 bit Windows, you will need to install the 32 bit version of Diskeeper; the autorun program will handle that for you as well. The same support in Diskeeper (Professional editions and above only) will be available for Vista x64 operating systems as well.

Tags:

General

Vista RTM and Diskeeper

by Michael 9. November 2006 13:32
If you're reading this blog, chances are you've already heard that Vista is code complete. The RTM (release to manufacturing) version has already been delivered to select Microsoft customers as well as OEM manufacturers that build PCs. I talked with some Microsoft enterprise license customers (e.g. 40,000+ clients) who also run Diskeeper on all their desktops, and they are already building system images to roll out Vista. They are all very anxious to get a Diskeeper that runs on the Vista RTM code. Our OEM partners are also eager to get Diskeeper for their new PC images (Lenovo, Sony, etc...). As we have already been informing our enterprise customers, we are about a week or two away from offering a private field test version of a Diskeeper 2007 build that will run on the Vista RTM version. Starting earlier this year we offered a public field test build of Diskeeper 10. That Diskeeper beta product will continue to be available for a short while longer on our downloads page. A key reason why we don't have a beta for RC2 is that we discovered some minor bugs in Vista (RC2) that affect some advanced Diskeeper features. We reported these to Microsoft, and they have fixed them in the RTM version. If you have the RTM version of Vista , you can participate in our private field test. Email our team at FieldTest@diskeeper.com with a quick note you'd like to test and that you have the Vista RTM build available to test on. If you are Diskeeper 2007 customer (just purchased or have a software assurance agreement), the update to Diskeeper 2007 that supports Vista will be free. More to come on how to get that will be emailed to you in the coming weeks. We're also targeting to have trialware available for Vista later this month on our website, possibly extending into early December.

Tags:

General

FragShield

by Michael 8. November 2006 02:32
Fsutil, allows you to to adjust the max size for the reserved zone. example: fsutil behavior set mftzone 4 The values range between 1 through 4, with each equally 12.5% of the volume. E.g. a setting of 4 = 50% of the volume. There are few reasons to extend this, and you are better off to pre-allocate the MFT expansion with Diskeeper's FragShield than rely on the just-in-time expansion of the MFT into the reserved zone (less overhead, and elimination of the possibility of the MFT becoming fragmented). Use Frashield when the MFT is getting full (Diskeeper will notify you) or prior to adding a large number of files onto the volume. We have customers who leverage this feature for corporate HQ servers that are designed to receive many small files uploaded from branch locations. If you're a gamer installing games

Tags:

General

The Mystery of the Disappearing MFT Reserved Zone!

by Michael 7. November 2006 22:50

The Master File Table (MFT) is perhaps the best known metadata file in an NTFS file system. Essentially it works as a "table of contents" for all the files on your volume describing attributes such as file name or the location of the file extents on a volume, and in some cases part of a file's data as well (in some cases, all of file's data). For every file, there exists at least one record (standard - 1KB in size) in the MFT for a file. When the attributes (e.g. data) of a file, an attribute could also mean the actual data itself (not just descriptors), could not fit in the 1KB record, it is written on the disk outside the MFT. These file attributes, typically the file's data, are known as non-resident attributes. Non-resident describes the fact that they do not reside wholly in the MFT (where resident attributes* define the exact opposite).

As more files are added to an NTFS volume, additional records are created within the MFT to define those files. As files are deleted from a volume the space they occupied in the Master File Table (the file's former record) is marked as available for use, but it is not deleted. Unlike some tools designed for databases or virtual disks, there is no tool or native action to shrink the MFT down to only the actual "in use" records. In essence this means the MFT can grow but will never shrink.

Microsoft file system developers thought ahead as they initially created the file system. They wanted to mitigate fragmentation of this key metadata file. They implemented an extension to this MFT file for future growth. The design they devised is known as the MFT reserved zone. It is a reserved area of free disk space located at the end of the currently allocated MFT space. As new records need to be created, the design was that they would expand into this reserved area, not randomly elsewhere on the disk, and hence not fragment the expanded MFT file.

Up through Windows 2000, this reserved area was relatively fixed, though in Win2K, you could edit the size. In most all cases the reserved zone would go unused and eventually allow for allocation of non-resident attributes as all other free space on a volume, other than the MFT reserved space, is filled up. If that occurred, the likelihood of the MFT fragmenting becomes almost a sure bet.

In Windows XP the behavior of the reserved zone changed. It went from being a hard coded percentage of the volume (default of 12.5%), to a dynamic extension called, by Microsoft, an "NTFS internal hint". While Diskeeper received information on this change early in XP's development, little data has been published on this from Microsoft. Given that we are talking about file system minutia that few care about or even need to be aware of, I can't blame them. I have attached the following as one of few sources from "the horse's mouth" on the subject.

http://web.archive.org/web/20080505004838/http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/2kuptoXP.doc

That takes me, finally, to the purpose of this blog!

As I mention all too frequently, I frequent online technical forums and help out PC enthusiasts by sharing what I have come to learn or have researched about Window's file systems. I have noticed, in numerous forums, questions regarding the "disappearance of the reserved zone" on Windows XP clients.

Many users, possibly well familiar with Windows 2000 or adroitly attuned to XP over a period time, notice that the reserved space on XP volumes shrinks or disappears from views in a Diskeeper analysis (or that of the built-in defragmenter). While almost all note it has not affected their performance (it would not) there is understandably a concern as this is a change from what they are familiar with.

As empirical evidence presented by these users would suggest, it is not a performance issue, and is perfectly normal.

If you are curious as to the current size of this reserved zone on your NTFS volumes you can use fsutil.exe (file system utility), or for easier-to-read information (i.e. not in hexadecimal!), use NTFSinfo.exe from Microsoft Sysinternals
http://www.microsoft.com/technet/sysinternals/FileAndDisk/NtfsInfo.mspx

*Accessing resident attributes is much faster than accessing non-resident attributes. That is because the MFT record has to be accessed irregardless when accessing a file. If the request does not have to extend past the file record in the MFT to non-resident extents, that translates to less seek time (mapping extents) and disk head movement (retrieving data from the disk).

Tags:

General

Idle Resources Graph - requirement

by Michael 4. November 2006 01:07
This is brief update. Diskeeper 2007 uses Windows system counters to enhance awareness of other activties on the system. The Idle Resource Graph (also known as the InvisiTasking graph) requires access to performance counters, which are enabled by default on Windows 2000+ systems. A skillfull Diskeeper user detected that disabling paging (running without a paging file) on a x32-bit system and running Diskeeper causes the disabling of required performance libraries (disable performance counters). This causes the Diskeeper graph to show a blank screen and manual defragmentation jobs to error out. Perhaps the only legitimate reason for remiving a paging file is to conserve battery life/power consumption so it is obviously a very rare circumstance. So, for the time being, if you are running Diskeeper 2007, be sure to keep a paging file on one of your system's volumes.

Tags:

General

Month List

Calendar

<<  May 2017  >>
MoTuWeThFrSaSu
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar