On Sunday, 8 April 2012 at 13:55:21 UTC, Marco Leise wrote:
Maybe the kernel caches writes, but synchronizes deletes? (So
the seek times become apparent there, and not in the writes)
Also check the file creation flags, maybe you can hint Windows
to the final file size and they wont be fragmented?
My understanding is that a delete operation occurs after all the
file handles associated with a file are closed, assuming there
other handles were opened with file_share_delete. I believe
otherwise you get an error from the attempt to delete.
I'm doing some experiments with myFrag sortByName() and it
indicates to me that there will be huge improvments in delete
efficiency available on a hard drive if you can figure out some
way to get the os to arrange the files and directories in LCNs in
that byName order. Below are the delete time from win7 rmdir on
the same 2GB folder with and without defrag using myFrag
sortByName().
This is win7 rmdir following myFrag sortByName() defrag ... less
than 7 seconds
G:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
9:06:33.79
9:06:40.47
This is the same rmdir without defrag of the folder. 2 minutes
14 secs.
G:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
14:34:09.06
14:36:23.36
This is all on win7 ntfs, and I have no idea if similar gains are
available for linux.
So, yes, whatever tricks you can play with the win api in order
to get it to organize the unzipped archive into this particular
order is going to make huge improvements in the speed of delete.
