Intro Download and install Frequently Asked Questions Tips and tricks

Homepage







© J.C. Kessels 2009
MyDefrag Forum
May 21, 2013, 12:30:12 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Request new AddGapPerFile( regexp, gapsize ) action  (Read 647 times)
greynite
Newbie
*
Posts: 3


View Profile
« on: October 08, 2009, 08:47:44 pm »

"Database" style files like to grow incrementally over time, so it would be nice to have a convenient way to specify a per-file gap, without having to create separate zones + gap for each specific file.

e.g. .ost and .pst files, .edb files (used by Vista & Win7 search), NTUSER.DAT, .mdb files (MS Access), .mdf files (SQL Server)

Example usage:

FileSelect
  DirectoryName("Users")
FileActions
  # Give Outlook data files a little growing room
  AddGapPerFile("*.pdf", 256000)
  AddGapPerFile("*.ost", 102400)
  SortByName(Ascending)
FileEnd

Thanks,
Shawn
Logged
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7155



View Profile WWW
« Reply #1 on: October 08, 2009, 10:06:54 pm »

Thanks for sharing your idea, I appreciate it. It has been proposed several times before, but alas, Windows usually does not use free space behind a file to expand that file.
Logged
Kasuha
JkDefrag Hero
*****
Posts: 595


View Profile
« Reply #2 on: October 08, 2009, 11:45:37 pm »

Windows usually does not use free space behind a file to expand that file.

I think it is not completely true.

I have made an experiment. Created special disk layout which put one file called test.avi (20 megabytes long) approximately at 1/3 of the disk with big empty gaps before and after that file. Then I used a program (VirtualDub.exe) which I know that really takes already existing file, overwrites its contents and eventually extends it. With that I extended that file to 200 megabytes. The result was that the file was purely extended in place to the following gap, resulting in a non-fragmented file.

The problem with most document files is, though, that these files usually don't overwrite existing document files. The editor usually creates a new file and original file is renamed to backup or deleted, before or after the new file is created (depends on the editor).

Real database files are extended in extents which are usually tens of megabytes long. Taking into account high internal fragmentation of database files (which consist of mix of data and index pages), a little fragmentation on extent boundary does not matter too much, especially if they get eventually defragmented.

Another problem of the proposal is, that it would create a lot of small gaps on the disk which would very probably get filled by some large file during normal system usage and that would cause that file to become unnecessarily heavily fragmented.
Logged
greynite
Newbie
*
Posts: 3


View Profile
« Reply #3 on: October 09, 2009, 06:04:39 pm »

Real database files are extended in extents which are usually tens of megabytes long. Taking into account high internal fragmentation of database files (which consist of mix of data and index pages), a little fragmentation on extent boundary does not matter too much, especially if they get eventually defragmented.
Excellent point -- there really isn't much that will be gained by optimizing the physical file assuming it has reasonably large fragments

Another problem of the proposal is, that it would create a lot of small gaps on the disk which would very probably get filled by some large file during normal system usage and that would cause that file to become unnecessarily heavily fragmented.
This one point I'd disagree with -- there will only be a handful of said files, thus only a few gaps available.

Overall though I'd say not of great value (particular considering Kashua's first point above). Thanks folks.

Cheers,
Shawn
Logged
jeroen
Administrator
JkDefrag Hero
*****
Posts: 7155



View Profile WWW
« Reply #4 on: October 09, 2009, 06:58:08 pm »

there really isn't much that will be gained by optimizing the physical file assuming it has reasonably large fragments
I think you mean defragmentation? See the ChunkSize setting of the Defragment command.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!