partioning HD w/NTFS

[Guest]

I have 2 HDs on my PC, on the master (80GB) I have XP pro and everything
else. On the slave(40GB)I put a paging file and nothing else. I want to
partition so that my O/S is alone on the master ;so what size will suffice
for the O/S? I then want to put all the hot fixes into a folder on a seperate
partition. Then all my games on another then text files on another and so
on... Also concerning paging file. By having the paging file on a different
HD other than where the O/S is I'm concerned about the memory dump. How
large should I make the paging file on the master to handle the memory dump?
And how large should the paging file be on the slave which is accessed less?
I have 1 GB of memory to play with. Will the /S be able to access the games
even if they are on a HD without an O/S on it?

 

[Richard Urban]

Placing the pagefile on a slave drive (connected to the same IDE channel)
buys you a sum total of nothing. In fact, it may slow the system down. The
two drives write consecutively. When one drive is in read/write mode the
other drive CAN NOT do the same. The time is split between the two drives.

Place the pagefile on a hard drive on the secondary IDE controller and you
can have concurrent reading/writing of BOTH drives. Here you will likely see
a gain if you are using programs that make extensive use of the pagefile.

--
Regards,

Richard Urban
Microsoft MVP Windows Shell/User

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!

 

[Rick \Nutcase\ Rogers]

Hi,

With a gig of ram, you'll likely not have much paging unless you're doing
autocad or heavy video editing, so placing it on a separate drive will not
really result in much of a performance gain. How big? You can go with
defaults, but I'd probably set the dump for a kernel dump on failure and the
pagefile for an initial size of 100MB just to see if it gets used at all (do
not set a maximum). Minimum size for the OS and associated stuff is
realistically around 2.5GB, but I wouldn't go less than 5 (room for temp
expansion during setup phases). Programs will run fine regardless of where
you install them to, they don't need to be on the system drive.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP

Windows help - www.rickrogers.org

 

[Jim Lewandowski]

Placing the pagefile on a slave drive (connected to the same IDE channel) buys you a sum
total of nothing.

***
Not so. By having the paging file reside on another drive, at least he can minimize head
(seek) movement. That's worth about 10 ms saved per seek. Again, if the paging file is
the ONLY file being accessed on the second hard drive or the one primarily being accessed
(few intervening files read off same drive of other files/folders), that would be of
benefit as the heads would always be parked right where Windows paging subsystem would
like them to be.

Remember, lots of background CONTINUAL disk accesses can/do occur with Windows/XP (NAV,
system tasks, NTFS logging).

Additionally, when physical paging occurs, it is usually a SYNCHRONOUS process to "real
work" (user applications) within the system . IOW, an applications use of memory has
caused Windows to physically page out other blocks of memory. Is there ever paging file
activity at the same time for OTHER disk accesses? Not likely. It can happen if one is
launching a new program (reading exe/dll stuff into memory forcing physical disk paging
into action).


In fact, it may slow the system down. The

two drives write consecutively. When one drive is in read/write mode the other drive CAN
NOT do the same. The time is split between the two drives.

***
See head/seek placement issue above.

Place the pagefile on a hard drive on the secondary IDE controller and you can have
concurrent reading/writing of BOTH drives. Here you will likely see a gain if you are
using programs that make extensive use of the pagefile.

***
The final question is: what % of the time is your paging file PHYSICALLY being written
to/read from?

JL

 

[Richard Urban]

Wrong. If something wants to read from the pagefile at the same time the
other drive is writing to disk, the pagefile read gets bumped momentarily.
It will have an adverse effect on your system. It is better to leave it on
drive C that to place it on a second drive on the same IDE controller. You
gain NOTHING by placing it on the second drive - same controller. You, in
fact, lose.

--
Regards,

Richard Urban
Microsoft MVP Windows Shell/User

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!

 

[Jonny]

Only thing you may gain with the swapfile on same bus/different hard drive
is lack of swapfile fragmentation of the XP drive. Ide still operates one
drive/device at time as Richard points out in so many words. In order to
get independent operation, the swapfile location must be on a hard drive of
a different bus. IE scsi or pseudo scsi, first hard drive seen on that bus,
first partition, nothing else including system restore on that partition.
That hard drive must be as fast or faster than the drive containing XP.
Note, I said nothing about Firewire or USB removable drive.

My advice for the swapfile size remains leave it alone, even in the advent
of overly adequate RAM conditions.

Applications, including games, should be put in their native install
locations. Any user files saved from any of these applications should be
saved to an alternate partition location if possible. Another hard drive,
even better.

 

[Jim Lewandowski]

Wrong. If something wants to read from the pagefile at the same time the other drive is
writing to disk, the pagefile read gets bumped momentarily.

***
Are we discussing this relative to 2 HDs on two different IDE controllers?

Even if we serialize access between the pagefile and non-pagefile files/folders, head seek
will have been minimized for the pagefile if on a separate PHYSICAL drive (not separate
partition on same drive as C.

You also say that the pagfile read gets bumped momentarily. That implies the priority of
pagefile I/Os is always LOWER than other I/Os (i.e. bringing new DLLs/EXEs into memory).
Even if that's true, reducing seek times for pagefile access even if on the same IDE
controller is better than leaving the pagefile on the C: partition.

It will have an adverse effect on your system. It is better to leave it on drive C that
to place it on a second drive on the same IDE controller. You gain NOTHING by placing it
on the second drive - same controller. You, in fact, lose.

***
Obviously having the pagefile on a separate IDE controller is potentially better (i.e.
assume we do have some pagefile I/Os). But having the heads on the 2nd PHYSICAL drive
attached to the SAME IDE controller is still potentially better (head seek) than having
the pagefile on the C: partition/hard drive.

JL

 

[Timothy Daniels]

Wrong. If something wants to read from the pagefile
at the same time the other drive is writing to disk,
the pagefile read gets bumped momentarily.

***
Are we discussing this relative to 2 HDs on two different
IDE controllers?

Even if we serialize access between the pagefile and
non-pagefile files/folders, head seek will have been
minimized for the pagefile if on a separate PHYSICAL
drive (not separate partition on same drive as C.

[.........]]
reducing seek times for pagefile access even if on the
same IDE controller is better than leaving the pagefile
on the C: partition.

[.........]
having the heads on the 2nd PHYSICAL drive attached
to the SAME IDE controller is still potentially better (head seek)
than having the pagefile on the C: partition/hard drive.

Right! Some people don't seem to get that it takes a
relatively much longer time to move the physical read/write head
around than to switch a logical context in the drive electronics.
Putting the pagefile on an otherwise little-used hard drive will
leave that drive's read/write head right over the pagefile.
And if that pagefile is on the outer tracks of the disk, more
bits per second will fly by.

The best strategy is to put in more RAM, though, to
reduce the frequency of pagefile use.

*TimDaniels*

 

[Jim Lewandowski]

Wrong. If something wants to read from the pagefile
at the same time the other drive is writing to disk,
the pagefile read gets bumped momentarily.

***
Are we discussing this relative to 2 HDs on two different
IDE controllers?

Even if we serialize access between the pagefile and
non-pagefile files/folders, head seek will have been
minimized for the pagefile if on a separate PHYSICAL
drive (not separate partition on same drive as C.

[.........]]
reducing seek times for pagefile access even if on the
same IDE controller is better than leaving the pagefile
on the C: partition.

[.........]
having the heads on the 2nd PHYSICAL drive attached
to the SAME IDE controller is still potentially better (head seek)
than having the pagefile on the C: partition/hard drive.

Right! Some people don't seem to get that it takes a
relatively much longer time to move the physical read/write head
around than to switch a logical context in the drive electronics.

***
I was generous with my 10 ms. It's closer to 15 ms for a 7200 RPM drive.

Putting the pagefile on an otherwise little-used hard drive will
leave that drive's read/write head right over the pagefile.
And if that pagefile is on the outer tracks of the disk, more
bits per second will fly by.

The best strategy is to put in more RAM, though, to
reduce the frequency of pagefile use.

***
My guess is that the user/OP isn't experiencing real physical I/Os to his/her pagefile.

JL

 

[PopS]

Too wide a brushstroke there, I think:
That's true only if the drives are all on the same physical
drive. Multiple physical drives can and do give an improvement
when they're set up properly.

Pop

 

[Richard Urban]

Please explain to all how multiple physical drives on the same IDE channel,
which operate consecutively - time sharing if you will, give an improvement
over multiple drives on two "separate" IDE channels which operate
"concurrently" - at the same time? We eagerly await the answer!

This whole thread is about two drives on either one IDE channel or two
drives on two IDE channels, and the way the pagefile is handled in each
scenario - if the pagefile is on a second drive (either same IDE channel as
the operating system drive or the secondary IDE channel).

--
Regards,

Richard Urban
Microsoft MVP Windows Shell/User

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!

 

[Jim Lewandowski]

Please explain to all how multiple physical drives on the same IDE channel, which
operate consecutively - time sharing if you will, give an improvement over multiple
drives on two "separate" IDE channels which operate "concurrently" - at the same time?
We eagerly await the answer!

***
The latter is obviously the most beneficial to performance (2 physical drives on 2
separate IDE controllers).

This whole thread is about two drives on either one IDE channel or two drives on two IDE
channels, and the way the pagefile is handled in each scenario - if the pagefile is on a
second drive (either same IDE channel as the operating system drive or the secondary IDE
channel).

***
However, my original point still stands for IDE #0 controller containing two PHYSICAL
drives.

If the pagefile.sys is on drive #2 on that IDE controller, the head seek issue will have
been minimized (provided drive #2 doesn't have all kinds of intervening accesses to othe
files/folders). This is STILL an improvement over having the pagefile on physical drive
#1 of which the C:/boot partition (assumed here) usually has lots of background I/Os going
on stealing the head from potential pagefile.sys accesses (whether reads or writes).

To reiterate: obviously having each drive on its own IDE controller offers the maximum
POTENTIAL throughput. But depending on how one uses the PC dictates what desired
configuration you would want.

JL