![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Patrick Elliott wrote:
> that are in the way? :(
I can show you how to get rid of most or all of those, btw.
It's probably either:
1) Encrypted file system data forks,
2) volume shadow copies (i.e., system restore files),
3) the USN journal
none of which can be moved by the normal defrag mechanism.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Patrick Elliott wrote:
> On a semi-side note. Had to defrag mine, which Windows doesn't normally
> allow. Page Defrag utility from sysinternals works nice (though I need
> to run it again, now that I succeeded in defragging all the files I
> couldn't, because the page file was in 33,000 pieces... O.o It runs
> before anything but the basics starts up, just after the initial loading
> screen, so pagefile.sys isn't yet in use.
>
> You would think, even with the slight overhead, trying to keep this
> thing in one chunk, as much as possible, would have been useful... Sigh!
You can use the defrag utility if you restart using Safe Mode + Command
Prompt. This might allow you to defrag the page file since lots of stuff
is being bypassed.
-Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Patrick Elliott schrieb:
> Still, point is, if you have memory free, open or not, I see no reason
> why, if you have free real memory, you couldn't page in some of the file
> that isn't "in use", page it back out someplace saner, etc. and defrag
> it that way. Ironically, its one thing I almost miss from the old
> Win3.11 days, where you could use Norton's defragger to defrag
> everything "including" the page file, and shift files you use a lot
> closer to the start, and unscatter directories, *and* consolidate free
> space.
Remember how, /theoretically/, you were supposed to actually /pay/ for
Norton Utilities back in those days?
Well, here may be news for you: There's still defraggers around for
sale, and which are said to perform better than the defragger MS is
giving away for free with their OS. ;-)
> I get that Windows defrag now does most of those, but it does
> them damned inefficiently, and no matter how many times you "force" it
> to consolidate files, it will flat out *refuse* to consolidate the free
> space, even when there is no sane reason to leave a handful of files
> scattered willy nilly over the remaining disk space.
Question is, what is the most efficient distribution of empty space
after a defrag? One huge consecutive chunk?
Actually, that's rarely the case. This is only good for drives
containing a huge collection of immutable files, like some archive. As
soon as you expect the contents of the files to change, it will actuall
be more efficient to have some free space after each file, to allow for
it to grow without fragmenting /again/.
So the strategy employed by Windows' free defragger is probably not too
bad - and don't forget it's a tool you get with the OS for free. (Not
developed by MS themselves, btw.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka schrieb:
>
> Question is, what is the most efficient distribution of empty space
> after a defrag? One huge consecutive chunk?
>
> Actually, that's rarely the case. This is only good for drives
> containing a huge collection of immutable files, like some archive. As
> soon as you expect the contents of the files to change, it will actuall
> be more efficient to have some free space after each file, to allow for
> it to grow without fragmenting /again/.
... furthermore, Windows' defrag apparently /does/ move files, but it
tries to arrange them in different sections, probably related to how
they are actually used/modified, or how large they are. Something along
those lines.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> soon as you expect the contents of the files to change, it will actuall
> be more efficient to have some free space after each file, to allow for
> it to grow without fragmenting /again/.
Interestingly enough, Windows actually does keep track of which files change
and which don't. Plus, it's probably pretty easy to guess in most cases. EXE
and DLL files? Pack em tight. Mailbox files? You probably want to leave some
space.
> (Not developed by MS themselves, btw.)
That may have been true a long time ago, but I don't expect it's true any more.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
>> (Not developed by MS themselves, btw.)
>
> That may have been true a long time ago, but I don't expect it's true
> any more.
Vice versa actually: They used to develop their own defrag, but then (I
think starting with XP) switched over to some lightweight edition of a
third-party tool. Raised a lot of fuss over here in Germany due to that
company's involvement with Scientology.
Well, maybe they acquired the developer of that tool by now, don't know...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> Darren New schrieb:
>
>>> (Not developed by MS themselves, btw.)
>>
>> That may have been true a long time ago, but I don't expect it's true
>> any more.
>
> Vice versa actually: They used to develop their own defrag,
No, they used Executive Software's DiskKeeper stuff. MS developed all the
APIs and such. Executive Software just wrote the user interface part (and of
course provided info on how the API should be designed). I'm pretty sure
nobody outside MS wrote software that frobs the NTFS file system to
rearrange blocks. (Granted, MS might have hired an outside company to
develop that, but it wasn't sold independently, so I don't count that.)
As for the defraggers on pre-NTFS file systems, I wouldn't really guess, but
Executive Software made the UI for the NT defragger.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
> clipka wrote:
>> Darren New schrieb:
>>
>>>> (Not developed by MS themselves, btw.)
>>>
>>> That may have been true a long time ago, but I don't expect it's true
>>> any more.
>>
>> Vice versa actually: They used to develop their own defrag,
>
> No, they used Executive Software's DiskKeeper stuff. MS developed all
> the APIs and such. Executive Software just wrote the user interface part
> (and of course provided info on how the API should be designed). I'm
> pretty sure nobody outside MS wrote software that frobs the NTFS file
> system to rearrange blocks.
"Diskeeper is a file system defragmenter originally for the VAX series
of minicomputers and later released for Microsoft Windows. It is the
flagship product of Diskeeper Corporation (formerly Executive Software).
The defragmenter program included with the Windows 2000, 2003, and XP
operating systems is based on a basic version of a previous Diskeeper
version."
(Wikipedia)
While the low-level code to perform the actual /swapping/ of individual
blocks of NTFS may well be MS stuff, /everything/ on top - including
such essential decisions as where to put which block of a file - is up
to individual software tools, and if MS did write anything of that which
is included in Windows XP, then apparently it's only the UI.
According to Wikipedia, the defragmenter that shipped with Windows 9x
was no MS stuff either, but licensed from Symantec.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> While the low-level code to perform the actual /swapping/ of individual
> blocks of NTFS may well be MS stuff, /everything/ on top - including
> such essential decisions as where to put which block of a file - is up
> to individual software tools,
Yes. But that's really pretty trivial stuff compared to actually writing
the code in the file system that makes it work.
Executive Software wrote the code to do the swapping on the VAX, too. I.e.,
they wrote *all* the code, not just the code to invoke the API to defragment
a file.
> and if MS did write anything of that which
> is included in Windows XP, then apparently it's only the UI.
If MS wrote the UI for XP, then everything is written by MS, since the UI
for XP just makes the decisions about where to put the blocks of the files
and swaps them. I.e., if MS wrote the UI for XP, and the algorithm for
picking which files to move where, and the API for swapping the blocks, then
they wrote everything, right?
I'm not sure I'm following. I'm just talking about it having two parts - the
UI, and the file system operations.
> According to Wikipedia, the defragmenter that shipped with Windows 9x
> was no MS stuff either, but licensed from Symantec.
Yes.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
> I'm not sure I'm following. I'm just talking about it having two parts -
> the UI, and the file system operations.
No, it's actually three parts:
(1) The UI to pick which drive to defragment, to visualize
defragmentation status, and to show a report afterwards
(2) The decision-making where to actually put exactly which file (the
"business logic" so to speak)
(3) The low-level code to swap one particular block with another in a
safe way
I'm not too familiar with NTFS, but I expect (3) to be not too
complicated, even if it may not be as simple as with FAT partitions,
while (2) is the one that actually determines the quality of the
defragmentation result: For instance, whether files in the same
directory are kept close together, or whether they are grouped according
to other criteria; how much free space is inserted after each file; and
plenty more stuff like that.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |