Hi Michael,

I'm trialing Diskeeper 10.0 Professional Premier right now and using the I-FAAST defrag. Something strikes me as odd which is that everytime it runs it moves the same large files around. I for example have some large VMware images (3-16GB) and even though I haven't used some of these since I've been running DK it moves them everytime I run an I-FAAST job. I'm guessing that it isn't moving them far from where they currently are so the extra work seems futile. It seems as if some low-pass-filtering/averaging is needed for it to build up an idea of where the files should be optimally but to only move them every so often if the rearrangement is minimal (or will most likely provide minimal benefit). Can you please comment on this. I feel that I would like the I-FAAST feature but I'm not sure that this endless reordering of the same files is worth the extra huge step up in price.

Another thing is that it is confusing that I-FAAST is a seperate defrag job. I understand that it is more resource intensive and therefore it's good to be able to schedule it weekly with a normal defrag daily, but it seems that it would make more sense for it to somehow be an option of a normal job. It's just a little confusing not knowing whether I should schedule my I-FAAST job to run just before or just after a regular job or whether it doesn't make any difference, but it also seems like some unnecessary harddrive thrashing to have a regular job to a defrag then I-FAAST shift some of the same data around immediately after.

Could you also comment on how the Most Accessed Files are determined. The documentation mentions that I-FAAST isn't fooled by recently accessed files. This makes me think that there is some file-system hook constantly running that intercepts accesses to keep it's database up-to-date. An alternative is perhaps that on each subsequent run it looks at the last accessed timestamp and tracks whether a file is being modified between each successive run. It's curiosity more than anything, but I like to have a rough idea of how such things on my system run so that I'm comfortable with their performance impact.

On a related note, I have a program that periocially recurses the entire filesystem and CRCs the files. The resulting database is used for searching for files, tracking changes, and detecting corruption. Is such a tool that reads all files in the filesystem going to render I-FAAST ineffective by making it seem that all files are Most Accessed?

Hi Steven,

While I can't be too specific on "how", we do use information easily gathered as to frequency of access and without additional system overhead.

I can't say for sure that the tool you are running does not affect our algorithm, but it is highly unlikely. Most tools of that nature read, in some cases update, metadata in a way that would not affect what I-FAAST is monitoring. As an example of compatibility, snapshot-type software programs that track changes and do snapshots of those changes, does not affect I-FAAST's frequency of usage measurement.

I-FAAST may move files around in order to properly sequence higher priority data. You can see this in the visual displays by noticing groups of data in different sections of the volume. The information I-FAAST uses to make decision is one that adapts over time. If I-FAAST is enabled and executed immediately, it does not have the best data to work with as far as frequency of usage is concerned. It's usually best to schedule the actual I-FAAST defragmentation job one week after enabling it, affording it time to learn about the volume usage. Whether or not you want to run nightly I-FAAST jobs or weekly really depends on how dynamic the system is. Most systems would be best served by a weekly I-FAAST job.

I-FAAST also creates special free-space zones to attempt to boost new file creation performance as well. It's possible that the file activity you are noticing may be related to that. Because the placement for new file writes is proprietary (we only know the theoretical design from MS) the technology we apply is not perfect (nor could anyone else?s be for that matter).

One thing you can do is enable the Application Event Logs for files moved, and files defragmented by Diskeeper. If you suspect with that detailed logging that there is unnecessary file movement, we'd really like to know about it -there may be room for more improvement. Please contact Tech Support with the information. We would love to have detailed feedback that allows us to improve the product!

I agree with the points you bring up with respect to integration. You can expect that I-FAAST will continue to improve from both operational and benefit perspectives.

Hi Michael,
as i read above in your answer, you said "While I can't be too specific on "how"..., but the major question is does Diskeeper anyway depends on the ntfs last access time or it has its own algorithms to monitor the file access frequency ?

I ask this because a lot of system administrators disable the ntfs last access timestamp in order to improve disk performance and minimize I/O overhead when reading sequentially a lot of files. If Diskeeper I-FAAST depends somehow on this timestamp it would be better to clarify it.

I love your products for the Windows OS Platforms. Do you have any plans for supporting linux systems, ie, Fedora Core 4 (which we are experimenting with here). We are attempting to go web-based within our intranetwork for data entry, etc.. And if we switch to linux servers fully (we have one how that we use as an SQL server) I would be very interested in a defragger program for them. If not, could you recommend one in the interim, as I know it will only be a matter of time until you roll-out a competive product. Thanks so much. Love you guys there. Mike at NCL Worldwide.

Hi Michael,

I also use diskeeper with I-FAAST enabled and I always disable the access timestamp, I haven't noticed diskeeper doing anything different since when access is enabled or not but it would be good to know if diskeeper uses this information, then I can perhaps enable it if diskeeper does.

Dave

Sorry for the late reply on the questions about Last Access Time Stamp.

The answer is yes, we do use it in part. We use this data to aid in immediate actions when you first activate I-FAAST. However, this information is far less important in the long term as we use other techniques to silently monitor file access frequency over time. If you disable this (such as with fsutil) the only ramification worth mentioning is that I-FAAST won't "get started" for a longer period of time - up to a week. That hopefully explains your experience. The other possible explanation is that your file usage doesn't change dramatically over time, and therefore I-FAAST's sequencing of files doesn't either.