On Saturday, 7 April 2012 at 17:08:33 UTC, Jay Norwood wrote:
The mydefrag program uses the ntfs defrag api. There is an
article at the following link showing how to access it to get
the Logical Cluster Numbers on disk for a file. I suppose you
could sort your file operations by start LCN, of the file, for
example during compression, and that might reduce the seek
related delays.
http://blogs.msdn.com/b/jeffrey_wall/archive/2004/09/13/229137.aspx
I did a complete defrag of the g hard drive, then did parallel
unzip of the tz folder with rmd, then unzipped it again with the
parallel uzp. Then analyzed the disk again with mydefrag. The
analysis shows the unzip resulted in over 300 fragmented files
created, even though I wrote each expanded file in a single
operation. So, I did a complete defrag again, then removed the
folder again, and get about the same 109 secs for the delete
operation on the hd (vs about 17 sec on the ssd for the same
operation). The uzp parallel unzip is bout 85 secs vs about 17.5
sec on the ssd.
G:\>rmd tz
removing: .\tz
finished! time:109817 ms
G:\>uzp tzip.zip tz
unzipping: .\tzip.zip
finished! time: 85405 ms
G:\>rmd tz
removing: .\tz
finished! time:108387 ms
So ... it looks like the defrag helps, as the 109 sec values are
at the low end of the range I've seen previously. Still it is
totally surprising to me that deleting files should take longer
than creating the same files.
btw, here are the windows rmdir on the defragged hd and on the
ssd drive, and the third measurement is the D parallel rmd on
the ssd ... much faster on D.
G:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
14:34:09.06
14:36:23.36
H:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
14:38:44.69
14:40:02.16
H:\>rmd tz
removing: .\tz
finished! time:17536 ms
