[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110523003745.GA2248@openwall.com>
Date: Mon, 23 May 2011 04:37:45 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: software RAID; disk partitioning
On Sun, May 22, 2011 at 10:50:00AM +0200, Piotr Meyer wrote:
> On Sun, May 22, 2011 at 04:17:42AM +0400, Solar Designer wrote:
>
> > Example disk partitioning schemes for Owl:
> > http://openwall.info/wiki/Owl/disk-partitions
>
> Interesting. My approach is similar, I use following schema:
> / - first primary partition, 3 to 10GB (depends)
> swap - second primary partition
> /var - third partition or LVM, 10GB to max, depends from services
> /srv - fourth partition or LVM, if I need extra space
Thank you for sharing this.
> I have questions about Your schema:
> - why swap as first partition?
It's primarily just our convention, which could as well be different,
but there are some reasons behind it:
Hard disks tend to be faster closer to the beginning, and swap better be
fast in case it's ever used for real. For example, here are some
numbers for FUJITSU MBA3147RC disks (147 GB SAS):
root@...t:~ # dd if=/dev/sda of=/dev/null bs=1G skip=1 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 8.66763 seconds, 124 MB/s
root@...t:~ # dd if=/dev/sda of=/dev/null bs=1G skip=11 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 8.70962 seconds, 123 MB/s
root@...t:~ # dd if=/dev/sda of=/dev/null bs=1G skip=21 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 8.81921 seconds, 122 MB/s
root@...t:~ # dd if=/dev/sda of=/dev/null bs=1G skip=111 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 11.8405 seconds, 90.7 MB/s
root@...t:~ # dd if=/dev/sda of=/dev/null bs=1G skip=131 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 13.7237 seconds, 78.2 MB/s
Normally, swap is mostly unused, so having it in the middle (between
filesystem partitions) would theoretically increase seek distances when
those filesystems are accessed. (In practice, the disk's physical
geometry could be such that this isn't the case.)
> - why /space and not /srv or /home?
We needed to call it something. Before we started using OpenVZ, as well
as on some smaller systems where we don't allocate a /vz partition,
/space was/is actually pretty large. As you can see, we move /home
under /space.
As to /srv, we tend to use /opt for custom software installs, and we
normally don't separate it from the root fs. However, we don't store
those services' large and read-write data files in there - e.g., any
logs will go under /var/log/something-appropriate, where /var/log is on
/space (symlinked). That's when we didn't use OpenVZ. Inside OpenVZ
containers, all of this stuff is usually on the same filesystem anyway.
It is important to note that when you use OpenVZ, you must not run any
non-essential services on the host system. Doing so is against OpenVZ's
security model (matching-UID attacks from host to guest become relevant).
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
