keeping system registry files on separate partition...?

  • Thread starter Thread starter Ms. Linda A.W.
  • Start date Start date
M

Ms. Linda A.W.

Has anyone ever tried putting the windows system registry files (other than
per-user) on a separate partition? I notice on bootup from bootvis, a great
deal of accesses to the sys registry, (permanent & log). If these were on a
separate partition near the beginning of the disk, it seems this would
speed access and reduce registry fragmentation? Seems like it would make
sense to put something that is commonly written to on a separate partition
from normal "system" files that are less freqently updated... ??

Would it be a matter of getting registry entries to point to new copies
on new partitions and rebooting, much as registry-"defrag" utils attempt to
do now?

thanks,
-linda
 
No one's tried it because it's a silly idea. In the first place, the
registry cannot be broken into parts. In the second place, bootvis was
withdrawn long ago because Microsoft realized it was being misused by people
like yourself who don't understand its purpose or correct use. (Last I heard
it was available to system developers - the intended audience - by special
request.) In the third place, breaking up Windows into separate partitions
on the same hard disk makes the computer slower, not faster. And the truth
is, even when the swap file is placed on a second physical hard disk (an
idea supported by Microsoft), the vast majority of users will see no
measurable improvement in performance.
 
Ted said:
No one's tried it because it's a silly idea. In the first place, the
registry cannot be broken into parts. In the second place, bootvis was
withdrawn long ago because Microsoft realized it was being misused by people
like yourself who don't understand its purpose or correct use. (Last I heard
it was available to system developers - the intended audience - by special
request.) In the third place, breaking up Windows into separate partitions
on the same hard disk makes the computer slower, not faster. And the truth
is, even when the swap file is placed on a second physical hard disk (an
idea supported by Microsoft), the vast majority of users will see no
measurable improvement in performance.
Click to expand...
---
I often come up with silly ideas. That doesn't mean they don't
work. :-)
I understand how bootvis works. The reason MS withdrew it, is that
it broke with the arrival of P4 hyperthreading. MS didn't want to spend
time to fix the _unsupported_ tool (which still worked fine w/hyperthreading
turned off or on non-hyperthreaded machines). The reason of keeping it out
of the hands of people who didn't understand what the limitations were was
put on the website later. MS didn't want to field questions about why it
didn't support hyperthreading (as it was an unsupported tool in the first
place), thus, making it available to developers-only - for whom it was still
useful if they ran it in non-HPT mode. But then I'm sure you knew that. :-)

The registry is already broken into the parts I need. They are
stored in "Hives" (files) on disk. They are composed of a "fixed" (extensible)
store (the permanent registry), and a real-time journal to maintain registry
integrity and allow for recovery in case of system failure.

The non-user files are kept in "<windir>\system32\config" and have
names corresponding to Registry Keynames under HK_LOCAL_MACHINE:
SOFTWARE (&Software.log),
SAM (&SAM.log),
SECURITY (&Security.log)
SYSTEM (&System.log)

The user specific files are kept under a user's directory "<userdir>\user"
in a file "NTUSER.dat" (and journal NTUSER.LOG).

Disk read speed at the beginning of a disk is about 2x the speed of
sectors near the end of the disk. It seems having a fixed space for swap and
the system registry at the beginning of the disk would allow the fastest linear
reading of this area. While this may be of questionable value in swap, the
sytem registry has to be read off disk at boot. Having it stored at the
beginning of disk should allow for faster bootup, however, without actually
trying it, I don't know the amount of savings.

I was just wondering if anyone had tried it, had any pointers, had noticed
any difference.

Having "kindly" people tell me "it's not worth it" when
they have no evidence to back it up isn't especially helpful. Their
opinion on registry performance is even further suspect when they
don't even understand how the registry maps to files on disk or
that system registry entries map to files under the <windir>
directory and user-reg entries map to locations determined
by the user-profile dir.

Thank-you for your "kind", "experienced" and "knowledgable" advice.

*sigh*
Linda

(not trying to be prickly, but not liking thorns either)
 
Obviously you must have a dev machine to play with so here are the pointers.
Let us know what happens if you try it.

HKLM\SYSTEM\CurrentControlSet\Control\hivelist

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Has anyone ever tried putting the windows system registry files (other
than
| per-user) on a separate partition? I notice on bootup from bootvis, a
great
| deal of accesses to the sys registry, (permanent & log). If these were on
a
| separate partition near the beginning of the disk, it seems this would
| speed access and reduce registry fragmentation? Seems like it would make
| sense to put something that is commonly written to on a separate partition
| from normal "system" files that are less freqently updated... ??
|
| Would it be a matter of getting registry entries to point to new copies
| on new partitions and rebooting, much as registry-"defrag" utils attempt
to
| do now?
|
| thanks,
| -linda
|
| --
| Email: to send me email, then my address would be like
| 'earthlink' was 'tlinx' and 'net' was 'org'
 
Ms. Linda A.W. said:
---
I often come up with silly ideas. That doesn't mean they don't
work. :-)
I understand how bootvis works. The reason MS withdrew it, is that
it broke with the arrival of P4 hyperthreading. MS didn't want to
spend
time to fix the _unsupported_ tool (which still worked fine
w/hyperthreading
turned off or on non-hyperthreaded machines). The reason of keeping
it out
of the hands of people who didn't understand what the limitations were
was
put on the website later. MS didn't want to field questions about why
it
didn't support hyperthreading (as it was an unsupported tool in the
first
place), thus, making it available to developers-only - for whom it was
still
useful if they ran it in non-HPT mode. But then I'm sure you knew
that. :-)

The registry is already broken into the parts I need. They are
stored in "Hives" (files) on disk. They are composed of a "fixed"
(extensible)
store (the permanent registry), and a real-time journal to maintain
registry
integrity and allow for recovery in case of system failure.

The non-user files are kept in "<windir>\system32\config" and have
names corresponding to Registry Keynames under HK_LOCAL_MACHINE:
SOFTWARE (&Software.log),
SAM (&SAM.log),
SECURITY (&Security.log)
SYSTEM (&System.log)

The user specific files are kept under a user's directory
"<userdir>\user"
in a file "NTUSER.dat" (and journal NTUSER.LOG).

Disk read speed at the beginning of a disk is about 2x the speed of
sectors near the end of the disk. It seems having a fixed space for
swap and
the system registry at the beginning of the disk would allow the
fastest linear
reading of this area. While this may be of questionable value in
swap, the
sytem registry has to be read off disk at boot. Having it stored at
the beginning of disk should allow for faster bootup, however, without
actually trying it, I don't know the amount of savings.

I was just wondering if anyone had tried it, had any pointers, had
noticed
any difference.

Having "kindly" people tell me "it's not worth it" when
they have no evidence to back it up isn't especially helpful. Their
opinion on registry performance is even further suspect when they
don't even understand how the registry maps to files on disk or
that system registry entries map to files under the <windir>
directory and user-reg entries map to locations determined
by the user-profile dir.

Thank-you for your "kind", "experienced" and "knowledgable" advice.

*sigh*
Linda

(not trying to be prickly, but not liking thorns either)
Click to expand...

Touché! Game, set, and match! The problem, as I see it frequently, is
that women are just not supposed to be technologists. The women who are
MVPs in these newsgroups are constantly derided and diminished by the
know it alls who obviously are threatened when a woman enters the fray.

Anyway, you might change your nom to something gender neutral to keep
the pests at bay since your questions and comments have obvious merit.

Q
 
Ted Zieglar wrote:
<snipped>

.. And the truth
is, even when the swap file is placed on a second physical hard disk (an
idea supported by Microsoft), the vast majority of users will see no
measurable improvement in performance.
Click to expand...

Wahh! Not so Ted, not so.

I've just recently created 3 page files on a 4 platter set up.

I won't go into the details but a single page file was returning over 55
MB and now I get increased performance with 3 page files reporting upto
(so far today alone) usage of 38 MB per page file as determined by
(Bill's?) XP Page File Monitor

Empirical observation suggests the present set up of 3 page files is the
nest config I've tried so far
 
Ted Zieglar said:
No one's tried it because it's a silly idea. In the first place, the
registry cannot be broken into parts. In the second place, bootvis was
withdrawn long ago because Microsoft realized it was being misused by people
like yourself who don't understand its purpose or correct use. (Last I heard
it was available to system developers - the intended audience - by special
request.) In the third place, breaking up Windows into separate partitions
on the same hard disk makes the computer slower, not faster. And the truth
is, even when the swap file is placed on a second physical hard disk (an
idea supported by Microsoft), the vast majority of users will see no
measurable improvement in performance.

--
Ted Zieglar
"You can do it if you try."

Ms. Linda A.W. said:
Has anyone ever tried putting the windows system registry files (other than
per-user) on a separate partition? I notice on bootup from bootvis, a great
deal of accesses to the sys registry, (permanent & log). If these were
Click to expand...
on
a
separate partition near the beginning of the disk, it seems this would
speed access and reduce registry fragmentation? Seems like it would make
sense to put something that is commonly written to on a separate partition
from normal "system" files that are less freqently updated... ??

Would it be a matter of getting registry entries to point to new copies
on new partitions and rebooting, much as registry-"defrag" utils attempt to
do now?

thanks,
-linda
Click to expand...


Placing the swapfile on separate hard drive on the first and singular
exclusive partition for the swapfile, with other than the onboard ide bus is
best. Performance changes are minimal. In fact mine is perhaps a few
percent slower as the swapfile is on an ultrascsi hard drive on this
particular PC.
The purpose of a different bus allows access to both the system partition
and the swapfile partition at the same time.
The purpose of a separate hard drive is to minimize fragmentation of both
the swapfile and the system partition.
The purpose of a singular and first partition on a separate hard drive is
maximum spin speed (hard drives access outside to inside the platter) and
faster access.
The overall benefit is not performance, but solidity.
This works on XP, 2K, ME, 98/98SE, and 95/95A/OSR2.
Use of this has shown reboot automatic recovery from blue screen messages
requiring manual shutdown, and power loss from the utility company on many
of the OSes I've suggested. This compared with a default swapfile location.
Not suggesting that I know why, but I do know what I observe.
Click to expand...
 
"Wahh! Not so Ted, not so."

I did say "the vast majority of users will see no measurable improvement". I
wouldn't consider your setup as the vast majority. Glad it works for you.
 
Ted said:
"Wahh! Not so Ted, not so."

I did say "the vast majority of users will see no measurable improvement". I
wouldn't consider your setup as the vast majority. Glad it works for you.
Click to expand...
Extremely groovy :)
 
Back
Top