Author Topic: Swap on separate drive  (Read 6108 times)

brick

  • Guest
Swap on separate drive
« on: June 27, 2018, 01:26:29 pm »
I'm getting ready to install Warp 4 on a Dell e510 with 4mb ram and two 130gb drives.  Is it preferable to have the swap partition on a different drive than the OS?   It will be a dual boot WinXp/Warp4 box.  I figure drive 1 will have the os's and drive 2 will be an HFS warp swap partition and a large fat32 partition for user data and apps. 


Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Swap on separate drive
« Reply #1 on: June 27, 2018, 03:00:25 pm »
Quote
4mb ram

I assume you really mean 4 GB of RAM. In that case, you will probably never swap anyway, so it doesn't matter where you put the swap file.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Swap on separate drive
« Reply #2 on: June 28, 2018, 12:36:37 am »
..in theory though, if your system requires a lot of saw file activity then yes, it would make sense to put it on a drive that does not store the OS/Application/Data files...that way you are not waiting for a single resource to complete the command.

Here is a silly way to illustrate this: I deployed a RAM disk and that become my \tmp space, the benefit is that any utilities, such as ZIP packagers, etc, etc, now use that main memory as scratch storage...what a difference in terms of how quickly things move. To a smaller extent I saw similar improvement when I moved all of my ZIP files over to a separate disk earlier on...

xynixme

  • Guest
Re: Swap on separate drive
« Reply #3 on: June 29, 2018, 11:42:30 am »
If the OS is OS/2, then of course do, if possible, use up to 2 GiB RAM as RAM instead of using RAM as swap file space. The OP should probably use the HPFS drive, drive 1. Swapping should be a rather rare event.

Nevertheless: if you aren't using r:\ as a TMP setting, then does the OS create r:\TMP and r:\TEMP after a reboot, or may it be worth the efforts to create (and preferably hide, e.g. to avoid getting DELTREE'ed) those TMP directories?

Assuming normal usage instead of just managing huge ZIP files by appending small files frequently, when is the speed gain of using a RAM disk for TMP the most impressive?

What's a recommended size, e.g. to account for large 32-bit files? As large as about the largest ZIP file you've got?

A known advantage is that any reboot will clean up the directories, albeit cleaning software could delete even more files. And I tend to use a RAM drive when software does access the same data file a gazillion times (ZIP file password guesser, quick & dirty Rexx solution, ...), to avoid Microsoft's physical harddisk torture.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Swap on separate drive
« Reply #4 on: June 29, 2018, 04:33:08 pm »
Hi André,

...Nevertheless: if you aren't using r:\ as a TMP setting, then does the OS create r:\TMP and r:\TEMP after a reboot, or may it be worth the efforts to create (and preferably hide, e.g. to avoid getting DELTREE'ed) those TMP directories?

Assuming normal usage instead of just managing huge ZIP files by appending small files frequently, when is the speed gain of using a RAM disk for TMP the most impressive?

What's a recommended size, e.g. to account for large 32-bit files? As large as about the largest ZIP file you've got?
...

I have all of my temp storage mapped to the ramdisk, so basically:
1) \tmp - all apps using this
2) pmmail - for email included attachments
3) GCC - compile and link processing
4) ZIP - looking at contents of a zip file, etc

The setup for the above is accomplished with the following statements in my startup.cmd:

Code: [Select]
REM Create some temp directories on the Y: RAM drive
md Y:\gcc
md Y:\zipcntrl
md Y:\pmmail
md Y:\tmp

All in all, yes, there is a noticable improvement with all of the above producing a speedier system response. Obviously this is most noticable with large data sets. The other benefit to doing this in a ramdisk, and this is very pronounced with Firefox, is that anything d/l'ed during runtime such as PDF files for example get stored on that ramdisk, quick to access (but that's not a big deal), better yet at reboot all this goes away thus providing for an automated cleanup.

Because I had 4Gig of unused ram I allocated all of it to my ramdisk as HPFS filesystem.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Swap on separate drive
« Reply #5 on: June 29, 2018, 04:42:11 pm »

I have all of my temp storage mapped to the ramdisk, so basically:
1) \tmp - all apps using this
2) pmmail - for email included attachments
3) GCC - compile and link processing
4) ZIP - looking at contents of a zip file, etc

The setup for the above is accomplished with the following statements in my startup.cmd:

Code: [Select]
REM Create some temp directories on the Y: RAM drive
md Y:\gcc
md Y:\zipcntrl
md Y:\pmmail
md Y:\tmp

Better practice is to check if the directories already exist, for example if you accidentally run startup.cmd or like me, have the ramdisk set to preserve the contents after a warm reboot.

Code: [Select]
if not exist y:\gcc mkdir y:\gcc
if not exist y:\pmmail mkdir y:\pmmail
if not exist y:\zipcntrl mkdir y:\zipcntrl
if not exist y:\tmp mkdir y:\tmp

xynixme

  • Guest
Re: Swap on separate drive
« Reply #6 on: June 29, 2018, 09:46:30 pm »
Off-topic: the largest temp files here were rare, cached Mozilla files, FWIW. If the size of your profile is larger than expected, by a few hundredth MiBs, then I guess the MOZILLA-MEDIA_CACHE directory may contain files (without extension) worth viewing and deleting.

Quote
Better practice is to check if the directories already exist, for example if you accidentally run startup.cmd or like me, have the ramdisk set to preserve the contents after a warm reboot.

Code: [Select]
if not exist y:\gcc mkdir y:\gcc
if not exist y:\pmmail mkdir y:\pmmail
if not exist y:\zipcntrl mkdir y:\zipcntrl
if not exist y:\tmp mkdir y:\tmp

Additionally, "ATTRIB +S [dir]" seems to do what I want. A RAM DISK which appears to be empty and survives "RM * -R". I do use RAM disks for sloppy applications like a first HelloWorld.C project, reviews, test installs or some DataCheck.CMD project, so a clean root directory sometimes is nice-to-have.

I may consider writing a hopefully simple RUN=MAKEDIRS.EXE (implicitly with Dave's checks) to not start using a STARTUP.CMD on some systems. No big deal, introducing STARTUP.CMD with an inserted ATTRIB +S will work too.