System Enhancement Software. Complete Storage, Backup and Recovery Solutions.
|
||||||||||||||||||||||||||||||||||||||||||||
|
|
Diskeeper |
|
| Boost the performance of your VAX, Alpha and Itanium computers Diskeeper Features At-A-Glance • Diskeeper 7.3-1 operates completely automatically, with no attention from the System Manager. Just "set it and forget it." • INDEXKEEPER – a safe, fast method for defragmenting the index file on each disk. • Improved Fragmentation Analysis Utility – newly enhanced to report the percentage of disk fragmented and number of excess fragments • Supports v5.4 to v7.3 of OpenVMS on VAX, and v6.1 to v7.3 on Alpha. IMPORTANT -- this is a reminder: please ensure that you reinstall Diskeeper after upgrading VMS. • Diskeeper operates on live disks, while users are accessing files. Diskeeper is completely safe, and is guaranteed not to corrupt files or data. • Diskeeper defragments all kinds of disks and disk configurations. • Diskeeper uses minimal system resources, ensuring that there is no detrimental performance impact from defragmentation. • Diskeeper checks disk integrity, and will not perform defragmentation if a disk error is detected. • Diskeeper automatically adjust frequency of defragmentation to the level of fragmentation on your disks. • Diskeeper defragments free space as well as files. • Diskeeper never poses an access conflict between the defragmenter and users. • Diskeeper can operate completely automatically, it is flexible, and defragmentation can be easily adjusted, from scheduling to the defragmentation job itself. Call +1 (800) 275-6321 and order Diskeeper for all your Alphas, VAXes and Itaniums today! |
| ----------------------------------------------------------------------------------------------------------------- |
| The Problem: Fragmentation Fragmentation is a condition common to all operating and file systems. It is a condition in which files and free space are broken up and scattered in pieces (fragments) around a disk. Let's take a look at why fragmentation exists, and its true impact on performance. |
| ----------------------------------------------------------------------------------------------------------------- |
| The Solution, or the Problem? File fragmentation has been a sad fact of life on OpenVMS computers since they were first introduced. OpenVMS for both Alpha, VAX and Itanium fragments files, just like its predecessor, VAX/VMS, fragmented files. The VAX/VMS operating system was intentionally designed to allow fragmentation to occur - and the reasons for this are interesting. Prior to VAX/VMS, files were not fragmented. The predecessor to the VAX/VMS operating system, called RT-11 (for Real Time-11), required that all files be contiguous - no file could be split into two or more pieces. A file had a single location on the disk, and that was that. If the file could not fit into a single location, it was not created. This problem of not enough contiguous free space to create a file occurred every time a disk filled up, and the small disks used in those days filled up very fast. When files were deleted frequently, it was not unusual to have a disk reach a point where no more files could be created, yet the disk was only a little more than half full. Eventually, the VAX/VMS operating system was developed. The file system used with VAX/VMS had the capability to place parts of a file in different locations on the disk. With this breakthrough, a file could be created any time there was sufficient free space anywhere on the disk; the free space did not have to be contiguous. Back in the early days, there was no drawback to this mechanism. It really was "a feature, not a bug." Performance losses due to fragmentation, even when taken to extremes, caused very little difficulty for anyone. This all happened in the early 1970s, however, and disks were very small - incredibly small by today's standards. They were measured in thousands of bytes rather than millions, not to mention the billion-plus byte capacities we see today. As disk capacities increased, so did the effect of fragmentation on OpenVMS performance. Now, there is no end in sight. Deliberate fragmentation is no longer a feature - it's a bug. |
| ----------------------------------------------------------------------------------------------------------------- |
| Fragmentation's Impact on Performance The basic problem with fragmentation is that it slows down a computer system. Each time a fragmented file is read from or written to a disk, the system must perform a separate disk input or output (I/O) operation for each fragment. To read or write a file in a single piece requires a single disk I/O; a file in five fragments requires five I/Os, and so on. Unfortunately, it is not uncommon for a file to be fragmented into hundreds of pieces. Imagine the additional I/Os required to read or write a file in that many pieces! These additional (unnecessary) I/Os have a profound effect on system performance. Instead of taking the average 10 to 20 milliseconds to read or write the entire file, you need 10 to 20 milliseconds to read or write each fragment of the file. Accessing or creating a fragmented file can take 10 (or even 100) times longer than if the file were contiguous. Now, how exactly does fragmentation occur within OpenVMS? Whenever a new file is created, or an existing file is extended, the OpenVMS operating system scans for space(s) to store the new file (or the extended portion of the file). If a disk has been recently defragmented, the system will be able to save the file to a contiguous free space. New file creations (or extensions) will occur contiguously. This will continue until files get deleted or purged - therein lies the problem. Even if a disk has been recently defragmented, and there are large contiguous free spaces, OpenVMS will store the new file in the spaces where recently deleted files resided. If the previously deleted file was smaller than the new file, the new file (or file extension) is immediately fragmented! So what can be done about performance-crippling fragmentation? Read on! |
| ----------------------------------------------------------------------------------------------------------------- |
| The Solution: Diskeeper Diskeeper has been the best-selling defragmenter for OpenVMS for over ten years. It has been installed and run with confidence on thousands of sites the world over. What made, and continues to make, Diskeeper such a success? The answer lies in its ambitious design goals, set and met from the beginning. These design goals were defined very exactly before the product was produced, by extensive surveying of OpenVMS System Managers (called VAX Managers in those days). We then set out to meet every one of those design goals, and did so. Diskeeper was designed with the following in mind: • The product must be completely safe to use. • It must make OpenVMS operate more efficiently. • It should process any OpenVMS supported ODS-2 and ODS-5 disk. • It should process live disks without interfering with user access to files on that disk. • It should operate while OpenVMS is running without negatively affecting performance. • It should process system disks as well as user disks. • It should run without operator intervention. • Now, how was each of these design goals implemented? |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 1: Safe to Use The foremost design goal was to make sure that no data is ever lost - neither user data nor OpenVMS internal information. To accomplish this, the Diskeeper proprietary method for relocating files was developed. It uses the following criteria for accessing files: The contents of data files are never modified under any circumstances. Only one file is processed at a time, not the whole disk. Each processing pass is independent of other passes. No information is stored on any other device or in a "scratch space". A file currently in use is not processed. Diskeeper accesses a file in such a way that no user access can conflict with Diskeeper during the critical portion of the relocation process. Read and write checks are used in all I/O to verify that the relocated file is a bit-for-bit duplicate of the original. File relocation is aborted if any error is encountered, leaving the file in its original state. File structure integrity is verified before any files are processed. The program was designed to err on the side of caution. In other words, the program only moves file information on the disk when it is absolutely certain that no data will be lost, including file attributes. The only change to file attribute information is the physical location of the file on the disk. None of the file dates are changed and no reserved fields in the header are used to store Diskeeper information. Placement control is not changed unless Diskeeper is explicitly instructed to do so by the System Manager. |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 2: Make OpenVMS More Efficient When a file is moved by Diskeeper, it is made contiguous or, at the very least, less fragmented. If it is already contiguous, the file is not moved unless moving it would markedly improve the arrangement of free space on the disk (with plenty of contiguous free space, file creations are faster and new files tend to be created contiguously, or nearly so). Note that the goal was not "to make every file contiguous" or "to combine all free spaces into one large contiguous free space." Disk perfection is not a requirement to get better performance from OpenVMS. In fact, a perfect disk will perform no better than a nearly perfect disk. While a single giant contiguous free space will allow the creation of a single giant contiguous file, it does no more for performance than a small number of relatively large contiguous free spaces. It is not the difference between one 100,000 block space and four 25,000 block spaces that makes a difference in performance; it is the 30,000 three-block spaces that really hurt. Nonetheless, Diskeeper will do an excellent job of consolidating free space on your disks. But do not use this as a yardstick for measuring defragmentation benefits; it is the number of fragments into which your files are broken that really impacts disk I/O performance. How much better will your performance be? It can be anywhere from slight to dramatic - but the important point to remember is, how much worse would your performance be if you allowed fragmentation to build up? We can guarantee that if you allowed that to happen your performance would slow down and become worse and worse over time. Diskeeper maintains your performance and keeps fragmentation from coming back, ever. |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 3: Process any OpenVMS ODS-2 and ODS-5 Disk This design goal was accomplished by using OpenVMS itself to do the "diskeeping" wherever possible. Diskeeper supports the entire range of OpenVMS ODS-2 and ODS-5disk types: system disks, common system disks, quorum disks, user disks, volume sets, stripesets, shadow sets and all RAID configurations. It works in clusters whether the disk is on a local controller, an HSC, MSCP-served, LAVC-style-MSCP-served or SCSI cluster. It can deal with empty or full disks and anything in-between. Put simply, Diskeeper is designed for any Digital-supported configuration. Diskeeper works with all Digital and third-party disk controllers. Note that system disks and common system disks really are processed. Diskeeper does not merely exclude all files in system-rooted directories – it actually processes all files on a system disk except open files and a few reserved files that cannot be moved while OpenVMS is running from that disk. The same applies to common system disks. |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 4: Process Live Disks Without Interfering With User Access To Files It is not acceptable to force users off the disk while defragmenting it. To do so would be a case of the cure being worse than the disease. Access to fragmented files is better than no access at all. The only acceptable solution is to defragment on-line with users active on the same disk. Diskeeper was designed with this in mind, and accomplishes the task without compromise, primarily due to the following features: No File Access Conflict During most of the time Diskeeper is processing a file, it shares the file with any other users that may access the same file. The last step of processing the file, however, involves locking the file for a very brief period, the duration of two QIO operations, a matter of milliseconds. If another user requests a file that Diskeeper has locked, that request is suspended for the brief period until Diskeeper releases the file. Then the request is serviced. There is never an interruption of either process as a result of this delay. I/O Throttling Diskeeper limits its own I/O to the equivalent of disk I/O "idle time." This feature makes the impact of Diskeeper on the load of your VAX or Alpha virtually unnoticeable, even during peak levels of activity. This feature is particularly important on any system where I/O to the disks is usually at or close to the maximum possible throughput. Suspending defragmentation activity when users most need access to their data assures maximum system performance. Exclusion List Diskeeper gives the System Manager the option of excluding certain files from processing. The Exclusion List is evaluated at the start of each defragmentation run and the files specified (in the list) are skipped over by Diskeeper. On-Line Directory Moves Diskeeper moves directory files, provided the directory is not open. This allows larger contiguous free spaces to be made which, in turn, allows larger files to be defragmented. Caches Updated Diskeeper does take into account the file header cache, and makes sure that the file headers are correctly updated so that no data is lost. The extent cache is not changed. Open Files Ignored Files that are always held open are not processed by Diskeeper. These files can be made contiguous using our Frag Guard Write Defragmentation Software, sold as an inexpensive companion product to Diskeeper - contact your sales representative for details. As long as files remain open, they will be untouched by Diskeeper. |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 5: Operate While OpenVMS Is Running Without Negatively Affecting Performance Three steps were taken to assure that Diskeeper had the lowest possible overhead: First, Diskeeper is designed to be run as a detached process running at priority 2. With the typical OpenVMS system running user jobs at priority 4 and batch jobs at priority 3, Diskeeper will use only CPU time that would otherwise be idle. Priority 1 remains available for even lower priority jobs that you do not want to interfere with Diskeeper. Second, advanced system programming techniques were used to write Diskeeper, to assure the highest possible performance. It uses QIOs for I/O instead of high-overhead RMS services, and it copies a file only once - directly from its original location to the new location. No intermediate copies are made, so no scratch space or second device is required. Third, as discussed earlier, Diskeeper includes a built-in throttling capability. This mechanism effectively limits Diskeeper I/O to the equivalent of disk" idle time." |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 6: Process System Disks As Well As User Disks A system disk by itself has little need for defragmentation because few files are ever created on the system disk. The only files ordinarily created on the system disk are log files. These do not particularly affect performance because they are rarely, if ever, read. Some sites, however, put user files on the system disk, and smaller systems sometimes have only one disk for both system and user files. Diskeeper can be run on such a shared system/data disk without having to shut the system down and without making the system unusable during the processing. Diskeeper processes are automatically prevented from moving all system files that OpenVMS will be expecting to find in a particular location on the disk. There are two different ways in which this is done. First, any file that is open is not moved. In addition to open user files, this includes INDEXF.SYS on every disk and files such as PAGEFILE.SYS and all SYS$MANAGER:*.LOG files currently in use on a system disk. This includes installed images that are installed with the /OPEN qualifier, such as License Management, Cluster Server, Audit Server, Logical Name Server, and other operating system components. Second, some files are excluded from Diskeeper processing by file specification. Wild card file specifications are used to look up and identify the specific files on each disk to be excluded in this manner. Diskeeper, running on any CPU in a cluster with separate or common system disks, can process all disks accessible by that node, including system disks. |
| ----------------------------------------------------------------------------------------------------------------- |
| Goal 7: Run Without Operator Intervention Regardless of how much a defragmenter increases system performance, the System Manager has no need or desire for the added problem of figuring out how to run the defragmenter and taking the time to baby-sit it. System Managers need less work, not more. Accordingly, one of the primary design goals of Diskeeper was for it to do its job with little or no intervention by a human operator. We accomplished that in our design so well that a System Manager can literally install the software, start it up and just forget about fragmentation (and Diskeeper) thereafter. Diskeeper cleans up the existing fragmentation and then prevents it from returning. How does Diskeeper determine when to defragment a disk? It uses a heuristic formula, which means a formula based on feedback from the real world. Each time Diskeeper defragments a disk, it waits awhile and runs again. It compares the two passes and determines whether it had to work harder or not as hard the second time. If it had to work harder the second time, then clearly it waited too long, so it adjusts itself to wait a little less and work a little more often. If it had less work to do the second time, it adjusts itself to wait a little longer between passes. The waiting between passes saves Diskeeper from incurring unnecessary overhead. This automatic mechanism keeps Diskeeper running at just the right frequency to keep your disks optimally defragmented all the time with the smallest amount of system overhead. We've put in a lot of work to ensure that, with Diskeeper, you would get the best defragmentation product possible. Call +1 (800) 275-6321 and order Diskeeper for all your Alphas, VAXes and Itaniums today! |
| ----------------------------------------------------------------------------------------------------------------- |
| The Diskeeper 7.3-1 Difference - Comparing Diskeeper with Other OpenVMS Defragmenters We've said it a hundred different ways, thousands of times: You need Diskeeper. If you already have it,you need more. And if you have it on all your machines, get your System Manager friends and associates to buy it. Why do we keep saying it? Is it just because it's our product and we make money from it? We'd be lying if we didn't say that's part of the reason. We are a business, after all. But that's not all of it. The rest of it is, we believe Diskeeper is the best, the safest, the most reliable, the most efficient defragmenter there is. Our customers believe that, too! That's why selling more Diskeeper is the easiest sale we make. But for anyone not familiar with Diskeeper, it's certainly not enough to say, "it's the best," or "it's the greatest." Heck, anybody can say that. What anyone in the market for a defragmenter will want to know is, why? What's so special about this product, especially as compared with others? All right, let's get down to the nuts and bolts and find out. Diskeeper Set The Stage First of all, Diskeeper was the first defragmenter designed to run online, in the background, automatically. At the time of Diskeeper's release, all other defragmenters were offline defragmenters, which not only demanded user time and monitoring, but were also relatively unsafe. When Diskeeper was first announced, demand was overwhelming. A safe, reliable, online defragmenter? Give it here! That product almost single-handedly put Executive Software on the Inc. 500 list of fastest-growing companies four years in a row. Others tried to follow suit, altering their offline defragmenters to run online. But these also-rans never came close in quality, let alone sales. And Diskeeper remains far and away the best-selling OpenVMS defragmenter of all time. The reasons for Diskeeper's overwhelming success are, like many successes, simple and basic: • It operates completely automatically, with no attention from the System Manager. Just "set it and forget it." • It operates on live disks, while users are accessing files. • It is completely safe, and is guaranteed not to corrupt files or data. • It defragments all kinds of disks and disk configurations. • It uses minimal system resources, ensuring that there is no detrimental performance impact from defragmentation. • It checks disk integrity, and will not perform defragmentation if a disk error is detected. • It automatically adjusts the frequency of defragmentation to the level of fragmentation on your disks. • It defragments free space as well as files. • It never poses an access conflict between the defragmenter and users. While it can operate completely automatically, it is flexible, and defragmentation can easily be adjusted, from scheduling to the defragmentation job itself. These are the basic features that earned Digital News & Review's coveted Target Award eight years in a row. Successive versions of Diskeeper have simply been refinements and improvements on these basic features. |
| ----------------------------------------------------------------------------------------------------------------- |
| "Bells and Whistles" In trying to compete with Diskeeper, a number of other defragmenter vendors have come up with a number of "whistles and bells" - "features" designed to draw your attention from the simple basics that have made Diskeeper so successful. Let's compare these "features" with Diskeeper's reliable, automatic defragmentation and see how they fare. |
| ----------------------------------------------------------------------------------------------------------------- |
| "One Pass Optimization and Defragmentation" This is a phrase used by several vendors to knock the fact that Diskeeper uses a three-pass system of defragmentation, and doesn't "optimize." This is actually humorous, when you know the true facts of the matter. First, there are very sound technical reasons Diskeeper uses three passes, and second, there are equally sound technical reasons that Diskeeper does not "optimize." We'll take up optimization first, because it's almost more of a problem than the "one pass." |
| ----------------------------------------------------------------------------------------------------------------- |
| Optimization Optimization is a "feature" of some other defragmenters. The companies promoting them have a tendency to sort of lump defragmentation and optimization together, and in some of their promotional literature you can't really tell where one ends and the other begins. Optimization consists of the deliberate placement of files in certain locations in an attempt to minimize head movement. This is done after files and free space are defragmented. The theory is that "hot" files are placed closer to the middle of the disk so that the disk head will not have to move as much and save time. It's a great-sounding theory, and is put forth as a great performance solution. When you look at the facts, though, you see some major holes in the theory. In fact, the holes are so major that we're of the opinion that "optimization" proponents either don't fully understand OpenVMS or are just using optimization as a marketing gimmick. Hole 1. File placement capability in OpenVMS was designed for the realtime laboratory environment in which a single process has continuous control of the computer system. In such a system, the time consumed by head movement from one particular file to another can be critical to the success of the process. The system designer can minimize that critical time lag by calculating the ideal location for the second file in relation to the first and forcing the two files to exact locations. Then, when the process has completed reading the first file, access to the second is effected with minimal delay. (This is probably where the "optimization" concept originated.) By comparison, consider the typical interactive user environment. Dozens or even hundreds of interactive users might be logged on and active at any moment, running who knows what applications, accessing innumerable files willy-nilly in every conceivable part of a disk. How can one even hope to guess where the disks' read-write head might be at any given time? With this extremely random mode of operation, how can a disk optimizer state flatly that positioning such-and-such a file at such-and-such an exact location will reduce disk access times? It seems that such a statement is foolish and such file positioning is equally as likely to worsen system performance as to improve it. Hole 2. It is uncommon for an entire file to be accessed all at once, especially in database scenarios (when was the last time you heard of a user or application accessing an entire database?). It is far more common for only a few blocks of a file to be accessed at a time. Thus, in many cases, locating an entire file in the middle of a disk is wasteful at best and possibly destructive as far as performance is concerned. Hole 3. Let's assume for a moment that the optimization theory is completely correct and works exactly as stated; that "hot" files can be exactly identified and placed in an optimum position. How much head-seek time would actually be saved, once this is done? The theoretical maximum reduction in average travel time is one-quarter the average head movement time, after subtracting the time it takes to start and stop the head. If the average access time is 32 milliseconds (for an RA82 model disk) and 24 milliseconds of this is head travel time, the best you can hope for is a 6 millisecond reduction for each file that is optimized. On a faster disk, such as the RA71 (12.5 milliseconds), the potential for reduction is proportionately less - about 2 milliseconds. And what about the latest disks with average access times of 9 milliseconds or better? The reduction becomes less than negligible, especially when compared to the resources used to optimize. Hole 4. Speaking of resources, let's address that issue directly. What do you suppose it costs your system to analyze and reposition every file on your disk? We ran our own tests here, in-house, using an "optimizer-defragmenter", testing it against Diskeeper. It consumed two to five times the resources that Diskeeper did, to not even do as good a job of defragmenting. When you subtract such resource usage from the theoretical optimization savings, it is costing you performance to "optimize" files. Enough said about optimization. |
| ----------------------------------------------------------------------------------------------------------------- |
| Cost Justification: When Is a Diskeeper Purchase Worth It? Diskeeper has a unique position in the computer industry. It's not an application - it is an enhancement to the system itself. Therefore, the rules applied to its purchase can vary greatly from the purchases of other software products. When is it "worth it" to buy Diskeeper? 1. When you've already seen a benefit. This would, of course, be the number one reason. You've run Diskeeper, you've seen the consistent benefit from defragmentation, and you've long ago said goodbye to the hassles of backup and restore. 2. When you know you have a problem the product will solve. This reason also makes the purchase very "worth it." You've tested your system with a Fragmentation Analysis Utility and seen your files horribly fragmented. Or, you've tried (demo'd) Diskeeper on your system and seen a positive result. You're confident of the purchase because you know it will solve a problem you've proven you have. 3. When you want to get the most out of your existing hardware. These days, budgets are tight, and it can be very difficult to cost-justify a hardware purchase. Yet, management and users are pushing to increase performance. It can wedge a System Manager between a rock and a hard place. Handling fragmentation is a very basic step in maintaining the native performance of a VAX, Alpha or Itanium. Fragmentation worsens over time, eventually bringing system performance to a crawl. With Diskeeper, fragmentation is eliminated in such a way as it never returns, and your performance is maintained. Note that performance may not be increased at the time you install Diskeeper. But Diskeeper will keep fragmentation from degrading your performance. Diskeeper can go a long way in getting more out of your existing hardware, and can in fact help you delay costly hardware purchases. Now, those reasons stated, here are some that might not be so obvious: 4. The budget's tight, and purchases are hard to come by. "Excuse me?" you might ask. "Last I checked, this is a reason not to buy." The reasoning is simple: Diskeeper makes your system more efficient. If your budget is tight, you're going to need to squeeze every ounce of performance out of that system. Bear in mind this makes your jobs and applications more efficient, too. This makes your existing resources worth more. As in reason number 3, it will take your current hardware a lot further than it might have gone otherwise. Software costs a lot less than hardware. If you are in a restricted-budget situation, and you can get more out of the hardware you already have, your cost-justification is right there. 5. You'll be moving off the OpenVMS platform in the near future. "What?" you might ask, aghast. "Now you're being ridiculous." First, it's been our experience that, when plans are made to phase a system out, it's usually about twice as long as the company thinks before the system is actually phased out. So you may have that machine or those machines around longer than you think. Second, that system is going to be used while you've got it. You'll need to get as much as possible out of that machine or those machines. Handling fragmentation is a vital step in that direction, as detailed in reasons 4 and 5 above. 6. Based on system activity, applications, or other reasons, you've decided you don't need Diskeeper. "Now you've completely lost it!" You say. "How could that be a reason to buy?" Well, you're right, it isn't. But we highly recommend that, before you make such a decision, at least try the product. We offer free trial demos. Many people have been very surprised to find out how badly fragmentation was affecting their performance, and how much Diskeeper was able to help. |
| ----------------------------------------------------------------------------------------------------------------- |
| CONCLUSION The bottom line is, VMS Diskeeper maintains and in many cases improves performance, and extends the life of your system. For the short term, or for the long term, it's worth it. Our goal is to ensure you get the maximum defragmentation possible for the money you spend. For this reason, we are currently offering the best pricing we've ever offered on Diskeeper - including Site Licenses in many instances. Let us help you license VMS Diskeeper on all your OpenVMS machines! Call +1 (800) 275-6321 and order Diskeeper for all your Alphas, VAXes and Itaniums today! |
Alpha, VAX, Itanium/Integrity/IA64/I64, VMS and OpenVMS , and RT-11 are trademarks of Hewlett-Packard Company.
Diskeeper, and Frag Guard are registered trademarks owned by Executive Software International, Inc.
