![](/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) |
> But that's the problem: There *isn't* enough contiguous space for the
> large file to be stored unfragmented because there's a bunch of small
> files
> scattered all over the free space, and the defragmenter is refusing to
> move
> those files to make space, for an unknown reason.
After you've moved off the 1GB file the defragmenter might behave
differently?
Anyway, even if there wasn't 1GB of contiguous free space, the file will
likely not get fragmented as much as it is currently, so it won't do any
harm.
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) |
scott <sco### [at] scott com> wrote:
> > But that's the problem: There *isn't* enough contiguous space for the
> > large file to be stored unfragmented because there's a bunch of small
> > files
> > scattered all over the free space, and the defragmenter is refusing to
> > move
> > those files to make space, for an unknown reason.
> After you've moved off the 1GB file the defragmenter might behave
> differently?
I did that the first time, and it didn't make any difference.
> Anyway, even if there wasn't 1GB of contiguous free space, the file will
> likely not get fragmented as much as it is currently, so it won't do any
> harm.
I just want to know why the defragmenter is refusing to move those files.
I would also like to make the page file one single contiguous block in the
disk. However, I'm unable to do that because of those small files.
--
- Warp
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) |
> I just want to know why the defragmenter is refusing to move those files.
Did you try the command line version 'defrag'? On Vista at least, there
appears to be a -w option that "Performs full defragmentation. Attempts to
consolidate all file fragments, regardless of their size.". That might be
worth a shot, as it sounds from the wording that maybe the default is to
ignore small files or something?
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) |
Warp wrote:
> I just want to know why the defragmenter is refusing to move those files.
That makes two of us.
> I would also like to make the page file one single contiguous block in the
> disk. However, I'm unable to do that because of those small files.
System Internals has a "PageDefrag" tool for this exact purpose.
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) |
Invisible wrote:
> System Internals has a "PageDefrag" tool for this exact purpose.
Norton's defragger, at least, used to have a 'defragment free space'
checkbox. No idea why that wasn't a default setting, or why almost no
defraggers nowadays do that (haven't checked Norton anything in ages
ever since around when they started shoehorning themselves into the
whole system vs. being a more-or-less standalone app/suite of apps).
--
Tim Cook
http://empyrean.freesitespace.net
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) |
Warp wrote:
> I can't understand why both programs are doing this.
Possibilities: The small files are actually directories that someone has
open? The defragger has seen that it already looked at those files and
decided it won't speed things up to move them (i.e., stupid algorithm)?
Most of the old defraggers had an option to consolidate free space, but
the later versions seem to have eliminated that. Hey, here's a business
opportunity for ya. ;-)
I assume you're smart enough to try it with everything you can run stopped.
Try this:
http://www.dirms.com/home/docs/dirms1.asp
The CLI version is free. It takes forever to run, especially with the
defaults. But it claims to compact the files better.
This is why *compacting* garbage collectors are good! ;-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
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) |
Warp wrote:
> I'm not exactly sure XP survives such a transfer while still being fully
> bootable from the new drive. Does it?
You can do it if you put the files in the same place, maintaining the
fragmentation. :-?
> (I know from experience that a linux system can be fully transferred from
> one disk to another with a simple "cp -ax",
That's nice about Linux. All you need to do is fix up the grub stuff,
rewriting the boot sectors or whatever grub does when you reinit it.
> Anyways, it's just one fragmented file. It's not such a big deal. I'm just
> wondering *why* the small files are not being compacted to the beginning of
> the partition in order to create a larger contiguous empty space.
Because the calculation is "how much time will I spend moving it compared to
the time I spend defragging it." NTFS keeps track of how often you use each
file, too, so the system can look and say "he only accesses this once a
month; there's no benefit to moving it closer to its directory."
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
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) |
scott wrote:
> I don't see any big reasons why it wouldn't survive,
You can't copy the registry files (especially SAM) easily while the system
is running, for one. Restoring it to the new drive is also tricky for the
same reason. Basically, you'd have to write your own full-blown program to
do this. You can't just use the usual backup/restore stuff.
> There are also lots of 3rd party programs that will do
> this automatically for you, I'd be surprised if there wasn't a freeware
> one.
The only ones I found that actually work basically take images of the drive,
not individual files, meaning fragmentation persists.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
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) |
scott wrote:
> Did you try the command line version 'defrag'? On Vista at least, there
> appears to be a -w option that "Performs full defragmentation. Attempts
> to consolidate all file fragments, regardless of their size.".
No. Vista defrag won't defrag chunks if they're already >64M or some such
size. I.e., you can have a file with three 66M chunks and defrag won't try
to defrag it without the -w flag. Again, the cost/benefit ratio.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
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 <dne### [at] san rr com> wrote:
> Try this:
> http://www.dirms.com/home/docs/dirms1.asp
No dice. Also that simply refuses to move those tiny files, and is unable
to defragment that one big file. I even tried to boot to safe mode and run
it from there. No banana.
My C drive looks like this, without that big file and without the Windows
page file:
http://warp.povusers.org/snaps/c-drive.png
I can't understand what those small files are. They are not marked as
unmovable nor anything special. They just are there, and no defragmenter
is moving them.
(The master file table certainly takes a humongous amount of space.
Is that really normal?)
Btw, this is how it looks after I restore that one big file:
http://warp.povusers.org/snaps/c-drive2.png
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |