 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> Try analysing the drive with MyDefrag (http://www.mydefrag.com).
That program actually did the trick. It moved those tiny files to make
space. Now my C drive layout looks like this, *with* that huge file and
*with* the Windows page file:
http://warp.povusers.org/snaps/c-drive3.png
(AFAIK those gaps are intentionally left by MyDefrag. The idea is that
programs creating small temp files will create them in those gaps, and
since the gaps are close to the beginning of the disk, they will be faster
to access.)
So what were those tiny files which other defraggers refused to move?
I don't know. MyDefrag gave weird names to them. I don't remember exactly
now, but they were something like C:\$SOMETHING:$SOMETHINGE_ELSE
I don't remember the exact names, but they looked meaningful. Maybe they
were somehow related to the NTFS file system.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> 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.
MyDefrag was able to move those strange clusters, even though it uses the
regular defragmenter system API to do so...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> 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?
I don't think that'll help either. If he doesn't have a 1G hole on the disk,
and he can't move the files that are in the way, no number of flags is going
to compact the files. The -f flag doesn't affect that - defrag runs or it
doesn't.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Why can't you just copy all the files while the OS isn't running? eg
> from another PC/OS/LiveCD/boot disc?
You could if you have the permissions, of course. You just can't copy the
drive you booted off of because of the registry. Most specifically, you
can't copy *to* the drive you booted off of.
There are a few immovable files (like the one holding the boot code, the
MFT, etc). There are a couple types of unmovable files (like the system
restore checkpoints, which have coded in their data the cluster numbers they
represent). There are permission systems designed to keep you from writing
to the file that holds the security information. You can't use the normal
access mechanisms (i.e., "copy") to copy the registry files around because
of security concerns.
It's just much more complicated than Linux. It's not impossible, or nobody
would be able to back up their computer. But the only software I've found
that actually will make a complete backup and then *restore* it uses imaging
techniques, not per-file copying.
--
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 remember the exact names, but they looked meaningful. Maybe they
> were somehow related to the NTFS file system.
Anything with a $ at the front is a file in NTFS used to run the file
system. Everything on NTFS is actually in a file, so you have things like
$RECYCLE.BIN (not really a magic file, tho)
$MFT (basically, inodes)
$BOOT (boot file the boot sector points to - the "superblock")
$BITMAP (the free space bitmap)
$USN (unique serial number file - no ext3 equivalent I know of)
$JOURNAL (transaction journal)
You also have files for the keys used for encryption and security
descriptors. (In later NTFS versions, each different ACL is hashed into its
place in the security descriptor file and a pointer to it is stored in the
file. Apparently a space saving over storing the full ACL with each file.)
Stuff with a : in the name means you have a different fork of the file. Kind
of like how System7 had data forks and resource forks on Mac, except each
fork is a byte stream and you can have as many as you want. Forks that start
with a $ are used by MS, either the file system or the shell.
Without knowing the actual name, it would be hard to guess what they were.
Glad you got it fixed, tho.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> 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. :-)
On Linux I have things set up so that my whole desktop environment is
preloaded into RAM right after the login manager is started.
There is a tool that records file reads. You configure it to run, then
reboot, and login, maybe open some apps you usually use. Next time you
reboot, another tool will read the recorded log and use the readahead
syscall on them. The file list is even sorted by their physical location on
the disk.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> There is a tool that records file reads. You configure it to run, then
> reboot, and login, maybe open some apps you usually use. Next time you
> reboot, another tool will read the recorded log and use the readahead
> syscall on them. The file list is even sorted by their physical location on
> the disk.
Yeah, XP has that built in, and Vista to an even greater extent. But they
only work on (AFAIU) the demand-paged blocks, not entire files. Does the
Linux tool read an entire file, or just the parts that were paged in at
start-up? I suspect 5 seconds would be plenty to read all the login files if
the heads didn't thrash like mad.
It just seems like it could be done better. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Nicolas Alvarez wrote:
>> There is a tool that records file reads. You configure it to run, then
>> reboot, and login, maybe open some apps you usually use. Next time you
>> reboot, another tool will read the recorded log and use the readahead
>> syscall on them. The file list is even sorted by their physical location
>> on the disk.
>
> Yeah, XP has that built in, and Vista to an even greater extent. But they
> only work on (AFAIU) the demand-paged blocks, not entire files. Does the
> Linux tool read an entire file, or just the parts that were paged in at
> start-up? I suspect 5 seconds would be plenty to read all the login files
> if the heads didn't thrash like mad.
>
> It just seems like it could be done better. :-)
The command-line tools work in terms of whole files. The syscall takes a
file descriptor and a byte range.
readahead-watch(8): Watches the mount points given, or the root filesystem,
for files opened during the boot sequence and closed without writing to
them. Orders the list by on-disk position and then writes it to the output
file.
readahead-list(8): Loads lists from the given file and performs readahead(2)
on each entry.
readahead(2): populates the page cache with data from a file so that
subsequent reads from that file will not block on disk I/O.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> The command-line tools work in terms of whole files. The syscall takes a
> file descriptor and a byte range.
>
> readahead-watch(8): Watches the mount points given, or the root filesystem,
> for files opened during the boot sequence and closed without writing to
> them. Orders the list by on-disk position and then writes it to the output
> file.
>
> readahead-list(8): Loads lists from the given file and performs readahead(2)
> on each entry.
>
> readahead(2): populates the page cache with data from a file so that
> subsequent reads from that file will not block on disk I/O.
Yeah! That's exactly what I need on Vista. :-) Especially if it would read
the whole file in one blow, or at least each contiguous piece. The vista
mechanisms just don't really do the trick, I think.
Actually, with the USN, you wouldn't even need readahead-watch. Just parse
the USN journal since the last boot and build the list from that. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Yeah! That's exactly what I need on Vista. :-)
Or not even that, really. If exec() would just read the whole file into RAM
in one blow, it would probably be 10x as fast. I should be able to start up
half a gig of executables in well under 10 seconds, and I'm pretty sure I'm
not loading that much stuff up when I log in. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
