 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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.
Weird. I never really let it grind all the way through, but it did
defragment some stuff for me.
> http://warp.povusers.org/snaps/c-drive.png
I think I have an older (or freer) version of that program. I don't have all
those options. :-)
> 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.
My guess, offhand, would be either directories or small files the system
happens to have open for some reason.
Oh, wait... Do you have system restore turned on? I bet you can't move files
that are the backing store of virtual volumes. Try going into system on the
control panel and turning off system restore, and see if those files go away
after the system has had time to sync the drive.
Also, maybe consider scheduling a chkdsk on boot. Perhaps the blocks wound
up being marked used but aren't really used any more?
> (The master file table certainly takes a humongous amount of space.
> Is that really normal?)
It never gets any smaller. If you run chkdsk, it'll tell you how much of the
MFT space is actually in use. There's also "reserved but unallocated" space
at the end of the MFT (normally 1/8th your disk). You can put files there,
but the system will use that space last, because once your MFT is
fragmented, you can't defrag it.
> Btw, this is how it looks after I restore that one big file:
> http://warp.povusers.org/snaps/c-drive2.png
That's only 4 fragments or so. Doesn't seem too bad. But I can understand
the frustration of not being able to figure out what those files are.
I bet it wouldn't be *too* hard to write a program to tell you file names
and cluster numbers on stdout, so you could figure out which files they are.
(Actually, DriveXML will do that as part of backing up the disk, writing it
into the xml-formatted backup file, but then you need to actually back up
the disk to get that file using that program. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Jun 2009 21:33:21 +0200, Warp <war### [at] tag povrayorg> wrote:
>
> 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.
Try analysing the drive with MyDefrag (http://www.mydefrag.com). It will
show you what file occupies any given part of the disk.
> (The master file table certainly takes a humongous amount of space.
> Is that really normal?)
The size of the MFT will of course depend on the amount of files on the
drive, but can easily be 100 MB or more.
Also, keep in mind that Windows will by default reserve up to an eighth of
the drive for the MFT to grow into. Not all defraggers distinguish between
the two parts.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson wrote:
> Try analysing the drive with MyDefrag (http://www.mydefrag.com). It will
> show you what file occupies any given part of the disk.
Cool. He needs some SEO in there. I never found that, even when I was
looking for better defraggers. :-)
> The size of the MFT will of course depend on the amount of files on the
> drive, but can easily be 100 MB or more.
I think the allocated space is 1KB for each file, for the maximum number of
files you've ever allocated. I.e., 1KB per file, but it never shrinks.
> Also, keep in mind that Windows will by default reserve up to an eighth
> of the drive for the MFT to grow into.
Actually, it's at least 1/8th, and you can bumpt it up as high as 50% when
you first format the drive if you want. In case you know you'll have lots of
tiny files.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's some immovable files:
System restore files
Control panel->system->system restore
turn it off for now
USN journals
fsutil usn queryjournal c:
write down max size, allocation delta.
fsutil usn deletejournal /d c:
Frees the space. Takes a minute or so, actually.
Sync/checkdisk/reboot/whatever
Defrag (and pagedfrg if you're on xp)
Then turn back on system restore and
fsutil usn createjournal m=maxvalue a=alocdelta c:
See if that gets rid of your bits. Plus disk cleanup, of course.
Also, perhaps you at one time recycled a whooole lot of files, such that
your subdirectory under the recycle bin is especially large?
cd c:\$RECYCLE.BIN
dir /a
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Why does it take such a humongous amount of time? I can't understand.
Speaking of which, on a slightly different topic...
When I boot and auto-login, it takes about 3 minutes before everything is
all settled down and happy.
If I log out, then log back in again, I'm back within maybe 5 seconds,
because everything's already in RAM and such.
I bet the thing would boot way faster if it just loaded the entire
executable for everything it needs to load at the time the program is
launched, rather than letting demand paging fight it out. I have enough RAM
to comfortably hold everything I run, so why not? I guess that'll get put
in eventually. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't understand the problems I'm getting defragmenting.
>
> I'm trying to defragment my primary Windows partition, which is NTFS.
> It's failing to defragment one big file because there's "no space" for it.
> The file is about 1 GB in size, and there's over 9 GB of free space in the
> partition.
>
> The problem is that while defrag is defragmenting all the other files,
> for some reason it's only compacting *some* of the files to be at the
> beginning of the partition, but not others. The free space is scattered
> with tiny small files which the defragmenter is not compacting, even though
> it compacted other files just fine. The majority of the contents were nicely
> packed to the beginning of the partition, except for these hundreds of tiny
> files. And no, the tiny files are *not* marked as "unmovable". They are
> marked with the same color as all the other movable files.
>
> The other, lighter defragger is behaving the exact same way: It's just
> refusing to move these small files, and consequently failing to defrag the
> one huge file. No reason is given in either the visual representation of the
> drive (all these tiny files are colored as regular, movable data) nor the
> analysis reports for this.
>
> As a consequence, I simply *can't* add any file bigger than a certain size
> to this partition without it becoming fragmented. There isn't enough
> contiguous free space because of all these scattered tiny files.
>
> I can't understand why both programs are doing this.
>
The Norton one, which you "used to be able to get as a separate
utility", fracking Norton..., would rearrange things so that a) commonly
used files where all in the same space, things in the same directories
where in the same space, actual directory data was located near the
start of the disk, so it was accessed faster, and compacted "all" empty
space, so that your existing files where at the start of the drive, not
scattered all over the damn place. Then they came out with Win95, and
some files got "locked" so you couldn't move them at all, never mind how
fracking fragmented they got/made things, but it "still" used smart
rearranging on everything else. Now.. I have no idea what it actually
does, or it even technically available, especially as something other
than part of 3-4 other things you don't need, and slow the system, do to
them running in the background all the time.
I personally find it incomprehensible that nothing else anyone makes
seems to be able to do anything as "simple" as compressing used space to
the start of the drive, so your "unused" space is contiguous, never mind
being "smart enough" to defrag that big 1G file, even without "enough
room", by arranging other fragments to give you the space, instead of
just leaving them empty. Its like handing a moron a paint brush and
coming back to find themselves sitting on the top of the kitchen counter
whining, "I painted myself into a corner!", only.. there are sections of
floor, all in between them and the door, none big enough to jump to or
step on, but never the less "unpainted", which they planned to "get back
to later". :p And, that the MS defrag takes the idiot amount of time it
does to paint itself into that same corner... Obviously mentally
challenged, "as well as" stupid. lol
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>
Simplest answer is, it behaved that way in 3.11, when it was "even more
critical", and MS never bothered to steal the idea of fixing it from the
few companies whose products **did** do it. ;)
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> Simplest answer is, it behaved that way in 3.11, when it was "even more
> critical",
Huh? Did MS make a defragmenter for Win3.11? I thought it was just the dos
defrag? All the third-party defrags I remember using did a fine job of
defragmenting absolutely everything.
> and MS never bothered to steal the idea of fixing it from the
> few companies whose products **did** do it. ;)
Cite? Certainly the XP defragmenter moves files around to open up free
spaces. I suspect it's just files that have absolute addresses in them,
like the UNC and system restore points.
Hey Warp, if you get it defragged, let us know what it was? :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> I personally find it incomprehensible that nothing else anyone makes
Everyone uses the same API. If there's a reason the files can't be moved, no
program is going to be able to move them.
> seems to be able to do anything as "simple" as compressing used space
Clearly it isn't that simple.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
Ah ok, I checked on my XP box and there is a -f flag, to force defrag even
with low freespace - maybe this would help Warp?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
