2nd HDD for var, tmp, usr/portage, swap

Hi,

as I have four hdd's in my computer, I was wondering if it
does make sense to 
source out some partitions/directories to a second hdd.

At the moment I have separate partitions for /var, /tmp and
/usr/portage (I 
feel portage is a lot faster since I've done this) on the
same hdd.

My question is if it makes sence to move these partitions to
another harddisk?

Rgds
Bernhard
-- 
gentoo-amd64gentoo.org mailing list

Bernhard Auzinger, mused, then expounded:
> Hi,
> 
> as I have four hdd's in my computer, I was wondering if
it does make sense to 
> source out some partitions/directories to a second
hdd.
>

There is no simple answer.  It really depends upon a lot of
factors - controllers,
drives, file system, memory, system bus...
 
> At the moment I have separate partitions for /var, /tmp
and /usr/portage (I 
> feel portage is a lot faster since I've done this) on
the same hdd.
> 
> My question is if it makes sence to move these
partitions to another harddisk?
>

Spreading them across drives could result in faster access
if the controllers
the drives are atached to allow overlapping commands.  IDE
doesn't do this and
can only have one drive active on the bus.

Also, some things - /var/tmp/portage, need fast read/write
access while /usr/portage
is a large number of small files  (things like Open Office,
gcc, firefox being
exceptions) and mainly read only access.  In many cases /tmp
is mainly an initial
write, then mostly read only access once the file get
built.

Also, it depends on where on the drive the partition
resides.  Swap is usually best
around one third to one half into the drive if the drive is
60% or more full.  Less
access time as the head idles arounf the swap area.

And as drives fill up, they will slow down as file seek
times increase.  Additionally,
different file systems will respond to the types of files
differently - lots of
small files, large streaming media files, indexed databases,
all require considering
the intended use.

In desktop use, I've watched the typical file i/o and can
say it tended to stay
below 4 or 5 MB/s peak for most things.  And I've seen raid
5 rebuilds sustain
225 MB/s on the same system.

So, sure move the r/w tasks off disks competing with other
r/w tasks and leave the
read only tasks on the man system disk.  You'll see a small
improvement, but in the
larger scheme of things, outside of uncompressing the
kernel, open office, firefox,
or gcc, it won't matter much more than 1% or 2%
improvement.

Bob
-  
-- 
gentoo-amd64gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernhard Auzinger wrote:
> 
> My question is if it makes sence to move these
partitions to another harddisk?
> 

Others have responded to this well already - one thing I
might add is to
check out lvm if you have so many drives.  Once you've used
it you'll
NEVER go back.  Depending on the filesystems you use it is
easy to
resize partitions after the fact, and moving them from drive
to drive is
a breeze even while they're active.

I'm currently running on 5 logical volumes on top of two
RAID-5 md
devices.  (With two more mirrored md devices for boot and
root).  Six
hard drives in total.  It took a little work getting to this
point, but
I can move stuff around easily while filesystems are online
and with
full redundancy on everything but swap (I could run swap on
my RAID-5
lvm partitions, but you take a performance hit there - and I
don't care
about a possible crash so much as the loss of lots of
data).

Oh, and for /tmp and /var/tmp consider using tmpfs - you
don't get
faster access times than virtual ram.  You might need to
fall back to
your hard drive for very large emerges unless you have
5-10GB of swap...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGoPFtG4/rWKZmVWkRAhikAJ9ZurXwpUpaicM9wQlhhnaydtCRRwCe
PK64
8DDSAfTvPZv6Ic+vgIwvt4c=
=Bf9I
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Freeman wrote:
> full redundancy on everything but swap (I could run
swap on my RAID-5
> lvm partitions, but you take a performance hit there -
and I don't care
> about a possible crash so much as the loss of lots of
data).
> 

Ok, here is a question.  I am using encrypted swap, with a
script that
creates a loopback off of my swap partition on each boot.

The problem is that if a drive fails and I reboot, the
device name for
the drives will change.  My mkswap could potentially wipe
out the wrong
partition in that case.

Now, I know that won't happen currently because my swap
partitions have
higher partition numbers than any of my data partitions. 
However, I'd
prefer to test for this possible condition.

Is there any way to get a unique identifier for a drive -
such as a
UUID?  I see hdparm -i returns a serial number (which I'd
need to parse
out), but it doesn't work for SATA drives.  Any ideas?  Then
I could
test the drive's unique ID before I start wiping out
partitions...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGoPOrG4/rWKZmVWkRAuraAJ4ulJpnWFYjW/0ISPXZGk4tKGAbpQCf
bVUf
mFNEmoEx/KItJYnJzjXQs4Y=
=xv13
-----END PGP SIGNATURE-----

> Is there any way to get a unique identifier for a drive
- such as a
> UUID?

Do you want the uuid or something else. With udevinfo you
get a lot of 
information.

udevinfo --query=all --name=/dev/sdb4 --root

Rgds
Bernhard

-- 
gentoo-amd64gentoo.org mailing list

Hello Richard Freeman,

> Ok, here is a question.  I am using encrypted swap,
with a script that
> creates a loopback off of my swap partition on each
boot.
> 
> The problem is that if a drive fails and I reboot, the
device name for
> the drives will change.  My mkswap could potentially
wipe out the wrong
> partition in that case.

Use cryptsetup-luks to set up encrypted swap partitions and
use /etc/conf.d/cryptfs to manage it. If you use a different
key for
swap, there's no risk of it unlocking the wrong partition
and formatting
it.


-- 
Neil Bothwick

The word 'Windows' is a word out of an old dialect of the
Apaches.
It means: 'White man staring through glass-screen onto an
hourglass...')

> Spreading them across drives could result in faster
access if the
> controllers the drives are atached to allow overlapping
commands.  IDE
> doesn't do this and can only have one drive active on
the bus.
They are two IDE-drives and two SATA-drives. The IDE drives
are each on a 
separate controller.

Thank you all for your replies. You've inspired me very well
. If
the 
weather will be rainy, I will move my /var/ partition to
another drive or 
maybe set up an LVM. But before I've to sleep a few  nights
over it.

Rgds
Bernhard
-- 
gentoo-amd64gentoo.org mailing list

Richard Freeman pisze:
> Is there any way to get a unique identifier for a drive
- such as a
> UUID?  I see hdparm -i returns a serial number (which
I'd need to parse
> out), but it doesn't work for SATA drives.  Any ideas? 
Then I could
> test the drive's unique ID before I start wiping out
partitions...

You can use alternative drives and partitions names created
by udev:

/dev/disk/by-id/* - named by drive model and serial number
  for example
/dev/disk/by-id/ata-SAMSUNG_SP0411N_S01JJ10L437449-part3

/dev/disk/by-path/* - named by device address on subseqeuent
buses,
  for example
/dev/disk/by-path/pci-0000:00:0d.0-ide-0:0-part1

Regards,
Marek Wróbel
-- 
gentoo-amd64gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Bothwick wrote:
> 
> Use cryptsetup-luks to set up encrypted swap partitions
and
> use /etc/conf.d/cryptfs to manage it. If you use a
different key for
> swap, there's no risk of it unlocking the wrong
partition and formatting
> it.
> 
> 

Hmm - not ideal if you store the key in a config file.  I
just create a
random key on each boot and it doesn't get recorded
anywhere.  As a
result it isn't possible to tell if a given partition is a
swap or
random data upon the next boot.  I could write something to
the
partition upon shutdown, but it won't help on an unclean
boot and I'd
rather not have to manually intervene anytime that
happens...

But thanks for the tip on the package.  I might still look
at it.  And
thanks to the other post about udevinfo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGoQ8IG4/rWKZmVWkRArDsAJkBEzsRNUEh48u3wtqVmKXkIod9YwCg
sb8H
Ud49d/Ft2ynjh+DZlNp2toM=
=zo74
-----END PGP SIGNATURE-----