September 2006 | Main | November 2006
October 27, 2006
What Does Diskeeper Mean By "RealTime"?
With Diskeeper 2007's introduction of real-time file system performance, some understandable questions arise or are reborn.
Exactly how "Johnny on the spot" is Diskeeper about file fragmentation and free space consolidation? Or for that matter, I-FAAST file sequencing or directory consolidation? A concern might be defragmenting temporary files that won't hang around very long, and are likely be maintained in cache for their entire existence.
How about excess power consumption and resultant heat from being busy all the time?
What about wear and tear on the drives? Won't a regularly active process cause the drive to have to work more?
These are great questions!
Diskeeper is aware of these very valid concerns, and handles them intelligently.
By design, Diskeeper doesn't defragment "within seconds of fragmentation occurring". It knows enough to wait an appropriate amount of time. That wait state can vary (minutes to hours), and is also dependent on available resources. Defragmentation of files is top priority, followed shortly thereafter by free space consolidation, and then directory consolidation and I-FAAST sequencing.
Another valid concern is generation of heat from an active CPU(s) and hard drive and the power consumption to operate and cool those components. The key here is that Diskeeper is only handling issues that, left unhandled, will result in even greater effort for those components when they are really needed. An ounce of prevention... (you know the rest).
When you first install Diskeeper 2007 it may well chug away at your file systems, even if you recently defragmented with Diskeeper 10. What Diskeeper is doing is applying some of the new performance technologies (such as directory consolidation), that were not performed in v10. It's typical to see your CPU (and the Idle Resources graph on the Dashboard) be busy around 40% or so. You'll find that after a short while, after Diskeeper has optimized your computer, that the resources drop off to 1% or less, with only the occasional spike as it learns of, and fixes recently "acquired" file system degradation.
One of the urban myths about defragmentation is that it could wear out your hard drive. That of course, is the exact opposite of what actually occurs. In addition to improved performance, regularly defragmented drives live longer than drives that are not defragmented. That is because the amount of work they have to do is reduced. Defragmenting a file in 100 pieces requires 100 disk I/O actions one time and then only 1 disk I/O every time that file is accessed - until the end of time itself or you delete the file (whichever is sooner).
Let's do some math. We'll take a file that is in 100 extents (fragments) that we will access 100 times over the next few years.
Case #1: Defragmentation (total disk I/Os required):
100 I/Os (to defragment)
+ 1 I/O * 100 (for each future access of the file)
----------------------
= 200 total disk I/Os
Case #2: No Defragmentation:
0 I/Os (to defragment - which we are NOT doing)
+ 100 I/Os (to access all the fragments) * 100 (for each future access of the file)
----------------------
= 10,000 total disk I/Os - aye caramba!
Note that the above is a simplification of the I/O activity to defragment or access a file - but it is a workable example. One thing Diskeeper continues to pioneer is the amount of total I/O generated to defragment a file. It generates far less I/O overhead than other technologies.
If Diskeeper were to needlessly shuffle files around all day, every day, all the above discussions would be moot. Power would be over consumed, drives would wear out too quickly, etc... However, Diskeeper does only what is needed to improve the performance of your file system - and no more. That design principle has always been at the core of what Diskeeper is all about, and it holds true with RealTime defragmentation just as it did with multi-pass defragmentation. The new benefit is now there is no waiting for peak performance - it just happens!
Posted by Michael at 05:22 AM | Comments (5)
October 26, 2006
InvisiTasking and BOINC
If you're reading this blog you probably have a good idea of what InvisiTasking is and what it does already. If not, you can read some of the earlier blogs on that subject for review, or check out an interview I did on Let's Talk Computers (http://www.letstalkcomputers.com/guests/diskeeper/invisitask/index.htm) or Computer Outlook (http://www.computeroutlook.com/dailyshows.php). BOINC is an acronym for Berkeley Open Infrastructure for Network Computing (http://boinc.berkeley.edu/).
While the two technologies are very different in their application, they do share the same principle. Both seek to leverage under-utilized computing power to do something positive.
BOINC is the backbone of numerous science research projects (a popular one is the SETI@home project). The key difference is that BOINC is a grid computing application (distributed computing). It uses wasted resources from an unlimited number of PCs across the internet (volunteer computing). It also offers distributed computing within a company network. InvisiTasking is a closed, single computer technology that does not communicate outside the computer and acts as the backbone of Diskeeper 2007. InvisiTasking is designed specifically for enterprise organizations, with a design focus on transparency of operation for applications used for business/security/productivity on a given computer. In short, they have different infrastructures and purposes.
BOINC also allows a system to run multiple BOINC-based applications concomitantly. InvisiTasking, for it's part, will behave similarly when other programs are built on that technology. Just as BOINC supports the SETI@home project as well as a project to aid in climate prediction, InvisiTasking will support simultaneous real-time defragmentation and, perhaps, a real-time anti-malware scan or file backup or database performance script.
For those, like myself, who contributed to the SETI@home project over the past years (there were 5.4 million volunteers), you knew that it used to run when your screen saver was initiated, much like a popular old Diskeeper feature. The brilliant folks on the BOINC project evolved their technology in parallel (though completely unrelated) with our brilliant R&D team here. The primary reason we evolved our older methodologies into InvisiTasking, is likely the same reason BOINC was introduced - to take better advantage of wasted resources -something screen saver mode was not effective enough at solving.
One thing we became aware of, in field testing, was that InvisiTasking was so resource sensitive that systems running BOINC applications took priority over Diskeeper's defragmentation. However, you don't need to choose between practical benefit for your computer and doing good for mankind.
If you are running SETI@hone or other BOINC applications, you'll want to make adjustments. There are two ways to tweak your computer to allow both programs to run harmoniously. The easiest (recommended) option is to alter BOINC. You can choose to operate as either a "Single User" or "Shared" rather than "As a Service" - and still use screensaver mode. If you do run it as a Service, you can edit your preferences to cap resources usage. BOINC also has a "snooze" button.
The other option (not recommended) is to make changes that alter InvisiTasking's behavior. If you do this, you are de-sensitizing InvisiTasking, so we recommend that you may want to consider disabling Diskeeper during certain periods using the graphical Automatic Defragmentation Timeline control. If you are a customer, Tech Support can advise you on this. Our FAQs may also include this information in the future.
Posted by Michael at 08:55 PM | Comments (5)
October 25, 2006
What do you want to see on the Diskeeper Blog?
Recently I've been active on numerous tech forums, helping out Diskeeper users and providing technical assistance or just general info on how the file system and OS work. It's giving me some good ideas for future blogs, but I'd really like to hear from everyone reading this blog what subjects you would like to see covered here.
As much as I like to hear myself talk ;-), I want to cover things you actually care to read. I want this site to provide benefit. Please think of it as a resource to help you out or provide you info you may not be able to get anywhere else.
I ask only that any subjects you suggest be loosely relevant to the technologies Diskeeper Corporation is involved with. On those subjects I can speak with, at least, a modicum of intelligence :-). Your request doesn't have to be on technical subjects. If you want to know more about the company itself - ask away.
Let us know what you'd like to see covered here! Please note that I may not post your comments until I get around to answering them in full.
Posted by Michael at 06:51 AM | Comments (9)
October 22, 2006
Fun with NTFS Data Streams
The following is a re-issue of an article written in June 2002 for the Diskeeper eLetter:
---
The NTFS file system contains an unheralded feature called streams. Using the stream facility, a single file can contain multiple streams of data, each separately addressable.
What could be done using such a facility? Well, if you remember old DOS-style database systems such as Paradox, youll remember that each database you made actually created a number of files. For example, if someone created Paradox database named films, hed end up with the files:
films.db
films.ix
films.r
If one of these files got accidentally deleted, the whole database was essentially deleted. If one needed to copy the database to another directory (folder), one would have to copy ALL the files to the new directory, or the database wouldnt function correctly.
What if all the files needed by a Paradox database could actually be folded into a single file? That would make accidental deletion of a single file harder, and would make the action of copying the database from one folder to another much easier and more reliable.
Using the stream facility, creating such a database system is much easier.
Using streams, a single file could be made, called:
films.pdx
Within that file could reside the streams
films.db
films.ix
films.r
At the Explorer level, however, all you would see is a single entry:
films.pdx
Lets have a little fun with streams...
(All the below examples were done on Windows XP. Your mileage may vary.)
(To run these examples, it is best to open a command prompt window. DO NOT USE THE RUN SELECTION FROM THE START MENU.)
Lets make a simple text file. Open a command prompt window and enter the command:
notepad testfile.txt
Notepad will, of course, ask if you want to create the file, and you say yes.
Enter the following string into notepad:
Once upon a midnight dreary
Exit notepad, saving the changes.
Back at the command prompt window, type the following command:
type testfile.txt
Of course, you get back the string Once upon a midnight dreary.
Now enter the following command at the command prompt:
notepad testfile.txt:hidden
(The quotes are part of the command.) Notepad will ask if you want to create the file, and you answer yes.
Enter the string into notepad:
While I pondered weak and weary
Exit notepad, saving the changes.
Back at the command prompt, enter the following command:
type testfile.txt
You get the line Once upon a midnight dreary again.
What happened to weak and weary?
Enter the following command at the command prompt:
dir
Well, theres no entry for testfile.txt:hidden, is there?
In fact, the directory output says:
06/18/2002 11:46 AM 27 testfile.txt
Hmmm. 27 bytes is Once upon a midnight dreary.
Enter the following command at the command prompt:
notepad testfile.txt:hidden
and lo! While I pondered weak and weary is still there!
Whats going on?
The line While I pondered weak and weary is in a stream whose name is hidden. Because it has a name, it is called, oddly enough, a named stream. The semantics for getting at a named stream are to take the file name (testfile.txt), append a colon (:), and append the stream name (hidden). The only way to get this past the command-prompt parsing in notepad parsing is to surround the whole string with double quotes.
Thats how we get the command
notepad testfile.txt:hidden
What about the midnight dreary string? Its contained in whats called the default or unnamed stream. The unnamed stream is what you get if you dont specify a stream name.
If we look at the MFT record for the file testfile.txt, it looks like this:
000000: 46494c45 30000300 4155925e 00000000 FILE0...AU.^....
000010: 0c000100 38000100 a0010000 00040000 ....8...........
000020: 00000000 00000000 04000000 c1620000 .............b..
000030: 0c000000 00000000 10000000 60000000 ............`...
000040: 00000000 00000000 48000000 18000000 ........H.......
000050: d00c70db f316c201 8070ad72 f816c201 ..p......p.r....
000060: 8070ad72 f816c201 8070ad72 f816c201 .p.r.....p.r....
000070: 20000000 00000000 00000000 00000000 ...............
000080: 00000000 82010000 00000000 00000000 ................
000090: 00000000 00000000 30000000 78000000 ........0...x...
0000a0: 00000000 00000200 5a000000 18000100 ........Z.......
0000b0: 05000000 00000500 d00c70db f316c201 ..........p.....
0000c0: d00c70db f316c201 d00c70db f316c201 ..p.......p.....
0000d0: d00c70db f316c201 00000000 00000000 ..p.............
0000e0: 00000000 00000000 20000000 00000000 ........ .......
0000f0: 0c037400 65007300 74006600 69006c00 ..t.e.s.t.f.i.l.
000100: 65002e00 74007800 74000000 00000000 e...t.x.t.......
000110: 80000000 38000000 00001800 00000100 ....8...........
000120: 1b000000 18000000 4f6e6365 2075706f ........Once upo
000130: 6e206120 6d69646e 69676874 20647265 n a midnight dre
000140: 6172792e 00000000 80000000 50000000 ary.........P...
000150: 000a1800 00000300 20000000 30000000 ........ ...0...
000160: 68006900 64006400 65006e00 2e007400 h.i.d.d.e.n...t.
000170: 78007400 00000000 5768696c 65204920 x.t.....While I
000180: 706f6e64 65726564 20776561 6b20616e pondered weak an
000190: 64207765 6172792e ffffffff 82794711 d weary......yG.
0001a0: 00000000 00000000 00000000 00000000 ................
0001b0: 00000000 00000000 00000000 00000000 ................
0001c0: 00000000 00000000 00000000 00000000 ................
0001d0: 00000000 00000000 00000000 00000000 ................
0001e0: 00000000 00000000 00000000 00000000 ................
0001f0: 00000000 00000000 00000000 00000000 ................
If you look at line f0, you can see the unicode name of the file.
If you look at line 120, you can see the data contained in the unnamed stream.
If you look at line 160, you can see the unicode name of the named stream. (Yes, its named hidden.txt, but whats a boy to do? We used notepad after all.)
If you look at line 170, you can see the data contained in the named stream.
Pretty neat, huh?
So, what problems are there with using data streams?
Well, as weve seen, only the UNNAMED data stream shows up in a DIR command or EXPLORER details. You cant tell how much data is contained in any named streams using standard user-level tools.
In fact, sometimes a file says its zero bytes, yet theres mega- or gigabytes in the named stream!
The problem with the lack of display data is that a malicious user could hide 12GB of data in a named stream, thus making your file server volume run out of space, and youd have no way to figure out whos eating all the space. This would be considered a classic denial of service attack.
Another problem, is, of course, that streams dont exist on FAT. If you copy a multi-stream file to a FAT volume, something funny will happen. All the streams will disappear except the unnamed stream.
So, we see that once an application begins to use streams, it can only run on NTFS volumes after that!
Posted by Michael at 11:10 PM | Comments (0)
October 19, 2006
Diskeeper 2007 will offer a free update to support Vista
We've had a number of questions on this:
When Diskeeper 2007 officially supports Vista (a few weeks away), the update build will be free to anyone who owns Diskeeper 2007.
Posted by Michael at 07:52 PM | Comments (8)
October 18, 2006
Getting Help With Diskeeper 2007 - Where To Go
The launch of a new product is a busy time for any software company and Diskeeper Corp is no exception. To prepare, we've improved our automation processes and increased staff in all areas that deal with our customers. The release is going very smoothly, but questions always come up, and our staff are hard at work helping everyone out. If you have questions or need assistance, below is a good list of places to find more information, and/or where send your requests for customers in North America:
For technical support, please visit: http://www.diskeeper.com/support/
If you have issues with the website, please email our Web Team: webmaster@diskeeper.com
If you have general requests, such as resending your software purchase/maintenance letter, please email our Customer Support Team at: service@diskeeper.com
You can find additional contact information at: http://www.diskeeper.com/contact/contact.asp
If you purchased from a reseller, please return to them for assistance. If you are located outside the US/Canada, please visit your respective Diskeeper reseller or partner.
Posted by Michael at 08:00 PM | Comments (4)
October 17, 2006
Just install it and let 'er rip! - Diskeeper 2007 is now available!
What best describes Diskeeper 2007?
I think beta tester Michael Ratledge (an IT security pro) said it best - "Just install it and let 'er rip!"
Diskeeper 2007 does what an automatic defragmenter should do. It defragments files on-the-fly without any impact on the system. Powered by new InvisiTasking technology, Diskeeper is the only technology that can truly deliver transparent operations.
Whether you are running a mission critical 24/7 enterprise server, or the latest graphics-intensive game, Diskeeper 2007 intelligently uses only unused system resources (if and when they are available). InvisiTasking goes far beyond the limitations of I/O and CPU throttling. There's simply no comparison.
What does that mean?
It means no more need to turn off your defragmenter, schedule at "off" hours, or manual defrag when you have a few minutes. And, Diskeeper 2007 is simple for the user - no need to figure out "settings" or what "type" of defragmentation is best for your system. Diskeeper does it for you, intelligently and dynamically determining what your system needs for peak file system performance!
Check out our product pages at diskeeper.com for more info, then download the trialware and take 'er for a spin!
Posted by Michael at 07:23 PM | Comments (32)
October 14, 2006
Invisible Software?
Below is the first part of a white paper on an amazing new technology our R&D team invented. We have big plans for this technology. I'd like to hear other venues where you think this technology could help? What programs are you running that could leverage this?
BTW: This report is a general overview of technologies in order to provide a better understanding of certain limitations inherent in modern operating systems. It is not a scientific study.
---
BACKGROUND MULTITASKING
OVERVIEW
Multitasking is a method for sharing system resources so that multiple processes can appear to run simultaneously. An example would be the ability to run both a word editor and a spreadsheet application at the same time.
However, a component in a general purpose computer, such as the CPU, can only execute one task at a given time. Multitasking presents the illusion that all execution is occurring simultaneously by implementation of a thread scheduling system. It is in essence virtualization of the CPU, designed to fool applications into believing they own the CPU exclusively. More powerful and faster CPUs can execute larger tasks or execute more in a given span of time.
Multiprocessing extends the principles of multitasking to multiple CPUs, actually allowing threads to run simultaneously, where multitasking only feigns this behavior. Multiprocessing, like multitasking, is still limited in processing capacity to one action at a time on a given CPU.
For the purposes of this paper, multitasking will be used to refer to the operating system's thread handling.
Inside Multitasking:
There are a variety of Multitasking techniques in use in operating systems today. Modern computer systems such as Windows, Linux, UNIX and Mac OS X use a form of multitasking called preemptive multitasking with varying unique differences. Pre-emptive multitasking is a more effective mechanism to guarantee resource sharing as it differentiates processes (e.g. I/O or CPU) and integrates I/O waiting so as to not delay processes that do not need I/O device responses (such as data returned from a hard drive).
Window's application of preemptive scheduling, while not a pure form, is more advanced, when compared to earlier MS-DOS based versions of Windows, in that it better separates processes by the resources they use (e.g. CPU intensive versus I/O bound). Of key importance is that it also allows processes to be prioritized. Prioritization involves implementing a system by which one process, and its associated threads, can be deemed to be more, equally, or less important than another process. An essentially "round-robin" scheduling system then assigns resource time-slices available to the active processes.
However, the prioritization value system is relatively rote in that it relies on the process to generally define how important it is. It also applies a numeric value system (values of 0-31) in which a higher number indicates greater importance. A process with a value of 8 will receive greater resource access than a process with a priority value of 4, but less than a process running at a priority of 13.
Processes that share a number value (e.g. word editor and spreadsheet that both have a value of 8) are considered equal, and must essentially "split" resources equally.
Ideal resource sharing systems would know more about unrelated processes that share a priority value, and be able to further subdivide resources. Then, based on actual needs at a given time, they could more effectively share resources, rather than relying on a relatively rote hard-coded priority value. Windows NT preemptive multitasking does not provide this.
Preemptive multitasking does provide a very basic implementation of dynamic resource assignment in order to ensure better system resource dissemination between high and low priority processes. The NT thread scheduling mechanism can dynamically adjust (increase or decrease) a priority value for a given process relative to its assigned base priority and to its I/O-CPU burst characteristics (i.e. a CPU bound process versus an I/O bound process) to afford eventual access to resources. The justification for priority changes is simply dependent upon whether a process is being starved resource time due to an influx of high priority processes. In these cases, the scheduler can dynamically reduce the priority of processes and increase the right to access resources for others.
The phenomenon related to this occurrence is that the scheduler will actually provide a lower priority I/O bound process a larger time slice than it normally would if it hadn't been starved. While the use of interrupts allows the blocking of I/O bound processes, it's important to note that a process will not be starved for more than 3-4 seconds. With processors operating in the gigahertz, a few seconds is retrospectively eons, but it will occur.
As one can see this system is beneficial to ensure that all processes get access to resources and that all processes are ordered in at least some simple form of relative importance.
However, some shortcomings can be uncovered with this design. It can be shown that some applications active on a system, that are allocated resources every 3-4 seconds, can and should be starved resources until no other process requires them. And, as suggested, prioritization amongst seemingly "equal" applications is relatively rote.
It becomes obviously inadequate when true low-priority applications that can wait indefinitely (or near-indefinitely) for resource allocation, are force-fed resources.
INVISITASKING, "True Background Processing - Delivered"
InvisiTasking is new technology designed to enhance multitasking and address some of the shortcomings related to the lack of "enough information". Having more information allows better sharing of resources. InvisiTasking is specifically designed to address the "background" application to ensure it truly does run in the background and does not interfere with higher priority processes such as transaction processing , print queuing and quite frankly, anything else other than wasteful system idle time.
Unlike multitasking, which is integrated in the operating system's kernel, InvisiTasking currently works in user-mode. This means it will not presently solve all the issues inherent in the core of multitasking for a background application, but it will mitigate the inherent shortcomings to the point they are no longer issues. It, of course, requires an application to be written to leverage this technology.
Inside InvisiTasking:
As CPU and I/O resources are almost never fully utilized, InvisiTasking's transparency is achieved by undetectably tapping into these unused system resources. Software engineers sometimes attempt to share resources by choosing lower CPU priorities to run under, and past efforts have been made at throttling disk and network I/O. However the goal of truly transparent software has never before been achieved until now.
To accomplish true transparency one needs to be able to monitor CPU, memory and the more significant hardware bottlenecks of the disk drive and network. InvisiTasking takes a pro-active approach to instantly detect resource usage while maintaining complete granular control over its own activity, ensuring that it never pre-empts users or services.
The key of course, is to prove that InvisiTasking theory holds true in practice...
---
Part two of this paper covers benchmark testing using PCMark and other methods - some really amazing results. Visit our Knowledge Center next week for the full paper (test results included).
I did a live radio interview with Computer Outlook. In between my mumbling and bumbling :-), I actually provide a few coherent comments regarding InvisiTasking (and later a bit on Diskeeper 10). It's about 30 minutes. http://www.computeroutlook.com/dailyshows.php
Posted by Michael at 08:20 AM | Comments (3)
Diskeeper and Vista
We've made Diskeeper 10 beta versions available since earlier this year. While we figured to learn more about Vista in the process, it was done primarily for those of you on the edge of new technology who wanted to use Diskeeper as you tested Vista. I noted in earlier blogs that we're very strict about the quality of software we send out, including beta software. That is why we went through stringent testing before we made each build available. That, in turn, means a time gap between a Microsoft build release and a Diskeeper beta release. It is a trade-off of time for quality. To date, we have received no major bugs reports (only a few install issues related to earlier UAC problems fixed in later builds of Vista). We've watched Vista "grow up" over the past year into a really solid and stable OS.
In the last few weeks/month we've been outpaced by Microsoft as they near their release. While it only takes a few days to test and change the code to release a new beta, these Diskeeper beta versions are at the mercy of other projects.
Our most important yearly project has been wrapping up, thereby taking all development and test time from other projects. That of course, is the next release of Diskeeper. At this time, the likelihood is that the next iteration of Diskeeper for Vista will be based on the next Diskeeper platform. And, when Vista hits the streets, Diskeeper will officially support it.
Posted by Michael at 07:47 AM | Comments (5)
October 07, 2006
Identifying Common Reliability/Stability Problems Caused by File Fragmentation
Earlier this year I wrote a white paper on fragmentation's effect on system and application reliability, presenting information about the root cause of the issue. Below is the first section of that paper. You can read the entire document in our Knowledge Center.
An Overview of the Problem
Having all program and data files stored in contiguous form on the hard drive is a key factor in keeping a system stable and performing at peak efficiency. Though unavoidable, the moment a file is broken into pieces and scattered across a drive, it opens the door to a host of stability/reliability issues. Having just a few key files fragmented can lead to crashes, conflicts and errors.
The principle of fragmentation's impact on system or application reliability is the timing out of a requestor or service provider in collecting/reassembling fragmented data. This principle holds true for both IP datagram fragmentation and file/disk fragmentation.
Many system and application breakage points can be defined as exerted stress on buffers to the point of overflow/overrun. DoS attacks are well documented examples of exploiting IP datagrams, but far less information abounds for reliability considerations in the case of file objects. A good overview of the affect of stress when requesting file objects comes from a Microsoft Knowledge Base article which states "The Server service cannot process the requested network I/O items to the hard disk quickly enough to prevent the Server service from running out of resources."
Disk fragmentation is often the straw that broke the camel's back when noting issues of stability or reliability. Stressed I/O activity, compounded by fragmentation can expose faulty device drivers or file filters that may otherwise operate effectively (in non-fragmented environments). The reliability of third party applications is highly dependent on the degree to which those applications can accommodate bottlenecks, such as in disk subsystems.
The point at which application or system stability is compromised is difficult, if not impossible, to calculate. It is a combination of hardware and software and operations at the moment of instability. A poorly written driver or file filter can be exposed in some environments but not in others, and the amount of fragmentation required to reach critical mass on a specific file or files, will vary greatly upon all the other variables involved.
This issue can be exampled by better understanding asynchronous I/O. Asynchronous I/O exists to compensate for variables that may prevent or eliminate the possibility of synchronous I/O (e.g. I/O is much slower than data processing). An alternative to handling I/O asynchronously, which generally offers lower performance, is to "block" other I/O.
Here is an example: a Win32 application creates either an I/O completion port, executes an overlapping completion routine, or calls WaitForSingleObject / WaitForMultipleObjects APIs at the time of thread creation. In any case where the wait state is exceeded (e.g. queued I/O is paged to disk), a failure can occur. As suggested, low available memory (non-paged pool) can exacerbate failures as it re-introduces the physical disk into the equation. In lieu of failures, extended queuing/waiting and proper exception handling can mitigate issues, at the expense of lower performance (operations take longer) for the application, or increased system resource requirements.
"The problem we were having was the server would get so busy that it would stop processing I/O requests and network traffic would just hang. Working with Microsoft and Compaq we concluded it was due to fragmentation. When we installed Diskeeper it resolved the problem overnight." -Mike N, System Administrator, John Deere
Failure to routinely address or understand fragmentation and its role in helping to cause these problems, results in increased IT staff workloads attempting to troubleshoot and identify the source of problems. This frequently leads to such common and often unnecessary actions as reinstalling software, re-imaging of hard drives, expensive replacement of hardware, an unnecessary work-around, as well as overwork at the Help Desk. Forcing IT to work reactively on problems, increases IT costs and adversely affects user productivity due to unacceptable levels of downtime.
Reliability and Stability Issues Traceable to Disk Fragmentation
The most common problems caused by file fragmentation are:
a) Crashes and system hangs/freezes
b) Slow boot up and computers that will not boot up
c) Slow back up times and aborted backup
d) File corruption and data loss
e) Errors in programs
f) RAM and cache problems
g) Hard drive failures
Posted by Michael at 01:15 AM | Comments (0)
October 05, 2006
Diskeeper Hugs a Tree
Due to a record pace for company software volume license sales in 2006 (thanks to our customers volume sales have been up 4 quarters in a row), Diskeeper Corporation is returning the favor to the environment. The next Diskeeper version will be using chlorine-free, recycled paper for its retail packaged Diskeeper products. And, it's a practice we plan to continue for the future.
http://www.marketwire.com/mw/release_html_b1?release_id=168621
The huge revenue boost also allows us to concentrate on the expansion of our R&D teams - we actually have two independently operating Research teams in addition to our product-specific development groups. It's the Research program teams that have produced some of the current defragmentation pioneering technologies in Diskeeper 9 & 10, as well as the industry-wide ground breaking new technology that is at the core of the new upcoming release. A recent key acquisition to the team is Rick Cadruvi, the original co-creator (with our CEO) of Diskeeper for OpenVMS (back in the 80's). Rick was well known as one of the premier industry experts on OpenVMS operating system design. With many years of in-depth technical expertise on Windows, he re-joins us as a technology leader, and is already quite busy inventing great new technologies.
Look forward as we (the staff of Diskeeper Corporation) return our thanks for purchasing Diskeeper Corporation products in the form of revolutionary and technology leading new products to make your computers run faster and more efficiently.
Posted by Michael at 12:54 AM | Comments (1)