Ray,
I defined eight vdisks as swap (the max that Linux can use, so I only have
to mess with fstab once), each double the other, with descending priority
so the smallest gets used first. When I see swap space starting to spill
into some of the larger vdisks, I may increase the virtual machine size,
and/or I may re-double the size of each in the VM directory, re-boot, and
continue monitoring. For example,
* /dev/dasds
MDISK 212 FB-512 V-DISK 2000 MR
* /dev/dasdt
MDISK 213 FB-512 V-DISK 4000 MR
* /dev/dasdu
MDISK 214 FB-512 V-DISK 8000 MR
* /dev/dasdv
MDISK 215 FB-512 V-DISK 16000 MR
* /dev/dasdw
MDISK 216 FB-512 V-DISK 32000 MR
* /dev/dasdx
MDISK 217 FB-512 V-DISK 64000 MR
* /dev/dasdy
MDISK 218 FB-512 V-DISK 128000 MR
* /dev/dasdz
MDISK 219 FB-512 V-DISK 256000 MR
Best regards,
Mark
"[EMAIL PROTECTED]
gov"
<[EMAIL PROTECTED] To
gov> [email protected]
Sent by: Linux on cc
390 Port
<[EMAIL PROTECTED] Subject
IST.EDU> Re: Best Swap Disk Strategy?
09/29/2006 01:48
PM
Please respond to
Linux on 390 Port
<[EMAIL PROTECTED]
IST.EDU>
Would it be something as simple as a response time test to decide which
swap algorithm to use? In a perfect world I'd like to simply give Linux
one chunk of v-disk, and let the OS figure out how to use it. As server
apps grow it gets riskier to mess with the fstab to add more v-disks,
and we also end up with a bunch of non-standard disk layouts unless we
plan well in advance.
In the mean time, I think I'll standardize on 3 progressively sized
v-disk addresses starting at .5 RAM, with no DASD swap.
Thanks.
Ray Mrohs
U.S. Department of Justice
202-307-6896
> It would need to be something that works for all platforms, not just
> for our virtual disks.
> The idea is that by using fresh slots you have a better chance to
> build long chains of adjacent blocks in a single I/O operation. If
> utilization is low enough, the "moving cursor" is an easy way to do
> that.
> With vdisk we're willing to take the overhead of many small I/O
> operations because the device is already fast enough (especially when
> your driver can exploit synchronous I/O completion).
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
