Advise for filesystem layout with DiskSuite
Jen Lu
development machine for our production apps. I want to use Solstice
DiskSuite to do a root/boot mirror and raid-5 for application data.
Here is what I have come up with so far:
Disk1:
/ (3GB)
/export/home (1GB)
swap (1GB)
/var (4GB)
Remaining disk space will include 3 slices of 9GB each to be assigned to
RAID-5 data volume
Disk2:
/ (mirror)
/export/home (mirrror)
swap (mirror)
/var (mirror)
Remaining disk space will include 3 slices of 9GB each to be assigned to
RAID-5 data volume
Disk3 - Disk8
I'll create 4 slices of 9GB each on all these disks.
So I'll have a total of 30 slices each 9GB size for my RAID-5 volumes.
This means I can have RAID-5 volumes of following sizes:
18GB (3 slices + 1 parity)
27GB (4 slices)
.
.
63GB max (8 slices spread across all disks)
My questions are:
1. Can I have a bigger (bigger than 63GB) RAID-5 volume with 8 disks of 9GB
each slice size? Or should I increase the slice size.
2. How do you grow the size of RAID-5 volume?
3. I don't see any point in distributing swap on muliple drives when it's
mirrored. Is there? What is the preferred layout?
Any help is appreciated.
Thanks
Jen
Lee Clemmer
"> 3. I don't see any point in distributing swap on muliple drives when it's
> mirrored. Is there? What is the preferred layout?
As the swap data is always temporary, there's no reason to take a
performance hit of two writes. If you're doing a significant amount of
swapping, performance is already not as good as you would like. If for some
reason the system crashed or the data became corrupt, the swap info would be
"cleared" (ignored) on a reboot anyway, why bother trying to preserve it?
I do recall that there was some (suggested) benefit to spreading the swap
slices across multiple disks. The location of the swap slice has some
bearing on it's performance as well, although again, I'm not sure that this
is really "worth it"--if you're doing enough swapping for swap performance
to matter you probably just need more RAM.
Lee
Joe Bloggs
can't read it, surely it'll cause a kernel panic?
"Lee Clemmer" <ne...@coolaquarium.com.com> wrote in message
news:bR5T7.44$M3.4...@newsrump.sjc.telocity.net...
Joe Bloggs
can't read it, surely it'll cause a kernel panic?
"Lee Clemmer" <ne...@coolaquarium.com.com> wrote in message
news:bR5T7.44$M3.4...@newsrump.sjc.telocity.net...
Joe Bloggs
can't read it, surely it'll cause a kernel panic?
"Lee Clemmer" <ne...@coolaquarium.com.com> wrote in message
news:bR5T7.44$M3.4...@newsrump.sjc.telocity.net...
Joe Bloggs
can't read it, surely it'll cause a kernel panic?
"Lee Clemmer" <ne...@coolaquarium.com.com> wrote in message
news:bR5T7.44$M3.4...@newsrump.sjc.telocity.net...
Logan Shaw
Lee Clemmer <ne...@coolaquarium.com.com> wrote:
>One brief point; in my opinion, don't mirror the swap.
>
>"> 3. I don't see any point in distributing swap on muliple drives when it's
>> mirrored. Is there? What is the preferred layout?
>
>As the swap data is always temporary, there's no reason to take a
>performance hit of two writes.
When swapping, the biggest performance hit by far is going to be on the
reads, not the writes. When the system gets low on memory, the clock
algorithm is going to churn through and evict pages from RAM. As long
as throughput on this is high enough to always keep some free pages
around, it doesn't really matter much how fast this goes.
On the other hand, when you fault in a page, that usually results in a
process blocking until that page can be read in. If you have mirrored
swap, then it's possible to get that page from whichever of the two
disks can get there quickest[1][2], because both have the data. This
could be significant, because seek time (well, access time) is going to
be the biggest part of the wait for the page fault.
My point is that mirroring swap could in some cases give you an actual
and significant performance increase. So you can't rule it out.
However, I have to agree that in most cases it's silly to optimize swap
performance and it's better to spend that energy/money avoiding
swapping altogether. And I do agree that mirrored swap does create
extra physical I/O, although if the disks are dedicated to swap, this
doesn't matter much at all. (But see note #2 about that...)
- Logan
[1] I assume this happens when you mirror swap on Solaris, although
I don't know it for an absolute fact. But if it happens for
filesystems, I don't see why it shouldn't happen for swap. (And
if it doesn't happen for filesystems, then DiskSuite is a really
poor program!)
[2] Actually, if the disks are dedicated to swap, they may have very
similar access patterns, so their heads may wind up being in
approximately the same place most of the time anyway, and so they
may both take about the same time to get there. In most cases,
you can assume the track number of one disk head is independent of
that of the other, but in this case, that assumption may or may
not be valid[3].
[3] I See A Great Need. :-) There needs to be a program (or a
DiskSuite feature) that causes the head of each disk in a mirror
set to seek to different regions of the disk (one near the
beginning, one near the end) periodically (once a second?) so that
one disk head really is more likely to be nearer to a given piece
of data than the other is. OK, maybe not, but it is not an
entirely bogus idea. At least it's not if the access pattern is
truly random.
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
Rich Teer
> One brief point; in my opinion, don't mirror the swap.
I think that's *very* illadvised. If a server is swapping
(paging), and swap is not mirrored, what happens if the swap
disk/partition becomes unusable? Bang: instant panic, or
worse, data corruption.
> "> 3. I don't see any point in distributing swap on muliple drives when it's
> > mirrored. Is there? What is the preferred layout?
Taking mirroring out of the equation for a bit, Solaris
stripes swap reads/writes to all swap partitions. Hence,
for a given swap size and usage, two swap partitions will
be faster than one IF THEY ARE ON SEPARATE SPINDLES (having
multiple swap partitions on the same spindle is a recipie
for a performance disaster!).
If you're going to mirror your multi-disk swap space, make
sure that ALL swap sub-mirrors are on different spindles.
> As the swap data is always temporary, there's no reason to take a
> performance hit of two writes. If you're doing a significant amount of
The two writes mostly occur in parallel, so the hit isn't as big as
you'd think. Especially if (as should be the case) multiple HBAs
(controllers) are being used.
> I do recall that there was some (suggested) benefit to spreading the swap
> slices across multiple disks. The location of the swap slice has some
> bearing on it's performance as well, although again, I'm not sure that this
> is really "worth it"--if you're doing enough swapping for swap performance
> to matter you probably just need more RAM.
Agreed, but a given machine can only hold so much RAM, and
there may not be sufficient budget to buy a bigger machine.
Disks are also cheaper per unit of storage, so although I
agree that if a machine is regularly paging/swapping, RAM
should be added to make up the short fall, sometimes that
isn't an option. E.g., if an E250 has got 1 GB of RAM in it,
and is frequently paging, a maximum of another 1 GB of RAM can
be added, if there's enough budget to do so. Alternatively,
1 GB or 2 GB of disk space can probably be found somewhere
to address the situation, at least temporarily.
As for the (slight) performance degradation of a machine
with mirrored swap: what is the performance of a machine
that has crashed because it's (un-mirrored) swap disk has
failed? Answer: 0.
--
Rich Teer . * * . * .* .
. * . .*
President, . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
*. / * \ . .
. /* o \ .
Voice: +1 (250) 979-1638 '''||''' .
URL: http://www.rite-online.net ******************
Stefan Berglund
> I want to use Solstice DiskSuite to do a root/boot mirror and raid-5
> for application data.
Software raid 5 with DiskSuite is a performance nightmare, I would
consider a raid 0+1 solution instead.
--
/Stefan
sbl+...@dd.chalmers.se
Life - the ultimate practical joke
Darren Dunham
> 2. How do you grow the size of RAID-5 volume?
Ugh. You can add a column to a SDS raid-5 metadevice, but that column
will never have parity on it. That means you have sort of a combination
of raid-5 and raid-4. It's doable, but strange.
I don't know that SDS allows another R-5 stripe to be created and
appended to the end of the first metadevice.
> 3. I don't see any point in distributing swap on muliple drives when it's
> mirrored. Is there? What is the preferred layout?
I would normally just mirror swap on the root disks unless you had
reason to believe that swapping was causing you performance problems.
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< How are you gentlemen!! Take off every '.SIG'!! >