* [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap @ 2007-07-20 14:41 Bernhard Auzinger 2007-07-20 15:13 ` Bob Sanders ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: Bernhard Auzinger @ 2007-07-20 14:41 UTC (permalink / raw To: gentoo-amd64 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-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 14:41 [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap Bernhard Auzinger @ 2007-07-20 15:13 ` Bob Sanders 2007-07-20 17:10 ` Beso 2007-07-20 17:31 ` Richard Freeman ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Bob Sanders @ 2007-07-20 15:13 UTC (permalink / raw To: gentoo-amd64 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-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 15:13 ` Bob Sanders @ 2007-07-20 17:10 ` Beso 0 siblings, 0 replies; 18+ messages in thread From: Beso @ 2007-07-20 17:10 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 2796 bytes --] the only thing that i've splitted is: /boot on a 100Mb partition, and this thing has saved me a lot of pain when something went wrong with the reiserfschecks when the pc ran out of energy with ext2 unjournaled, the /home partition, so that it could be used with different systems without reconfiguring with reiserfs, and a large file partition with xfs which has a very great large file usage.... i personally don't really think that splitting other / subfolders may have a great use on everyday use.... 2007/7/20, Bob Sanders <rsanders@sgi.com>: > > 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-amd64@gentoo.org mailing list > > -- beso d-_-b [-- Attachment #2: Type: text/html, Size: 3304 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 14:41 [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap Bernhard Auzinger 2007-07-20 15:13 ` Bob Sanders @ 2007-07-20 17:31 ` Richard Freeman 2007-07-20 17:40 ` Richard Freeman 2007-08-01 16:39 ` Bernhard Auzinger 2007-07-20 18:41 ` [gentoo-amd64] " Duncan 2007-07-20 18:47 ` [gentoo-amd64] " Bernhard Auzinger 3 siblings, 2 replies; 18+ messages in thread From: Richard Freeman @ 2007-07-20 17:31 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1424 bytes --] -----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/rWKZmVWkRAhikAJ9ZurXwpUpaicM9wQlhhnaydtCRRwCePK64 8DDSAfTvPZv6Ic+vgIwvt4c= =Bf9I -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 17:31 ` Richard Freeman @ 2007-07-20 17:40 ` Richard Freeman 2007-07-20 18:31 ` Bernhard Auzinger ` (2 more replies) 2007-08-01 16:39 ` Bernhard Auzinger 1 sibling, 3 replies; 18+ messages in thread From: Richard Freeman @ 2007-07-20 17:40 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1297 bytes --] -----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/0ISPXZGk4tKGAbpQCfbVUf mFNEmoEx/KItJYnJzjXQs4Y= =xv13 -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 17:40 ` Richard Freeman @ 2007-07-20 18:31 ` Bernhard Auzinger 2007-07-20 18:35 ` Neil Bothwick 2007-07-20 19:17 ` Marek Wróbel 2 siblings, 0 replies; 18+ messages in thread From: Bernhard Auzinger @ 2007-07-20 18:31 UTC (permalink / raw To: gentoo-amd64 > 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-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 17:40 ` Richard Freeman 2007-07-20 18:31 ` Bernhard Auzinger @ 2007-07-20 18:35 ` Neil Bothwick 2007-07-20 19:37 ` Richard Freeman 2007-07-20 19:17 ` Marek Wróbel 2 siblings, 1 reply; 18+ messages in thread From: Neil Bothwick @ 2007-07-20 18:35 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 721 bytes --] 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...') [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 18:35 ` Neil Bothwick @ 2007-07-20 19:37 ` Richard Freeman 2007-07-20 19:49 ` Neil Bothwick 0 siblings, 1 reply; 18+ messages in thread From: Richard Freeman @ 2007-07-20 19:37 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1062 bytes --] -----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/rWKZmVWkRArDsAJkBEzsRNUEh48u3wtqVmKXkIod9YwCgsb8H Ud49d/Ft2ynjh+DZlNp2toM= =zo74 -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 19:37 ` Richard Freeman @ 2007-07-20 19:49 ` Neil Bothwick 2007-07-23 13:53 ` Richard Freeman 0 siblings, 1 reply; 18+ messages in thread From: Neil Bothwick @ 2007-07-20 19:49 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1022 bytes --] Hello Richard Freeman, > > 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... I keep my keys on an encrypted partition, /etc/conf.d/cryptfs prompts for the key for that partition at boot. Then the keys on that partition are used to set up swap and /home before the partition is unmounted, so the keys are only exposed for 2-3 seconds per boot. -- Neil Bothwick Fasten your seatbelt ... I wanna try something. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 19:49 ` Neil Bothwick @ 2007-07-23 13:53 ` Richard Freeman 2007-07-23 14:05 ` Neil Bothwick 0 siblings, 1 reply; 18+ messages in thread From: Richard Freeman @ 2007-07-23 13:53 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1299 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Bothwick wrote: > > I keep my keys on an encrypted partition, /etc/conf.d/cryptfs prompts for > the key for that partition at boot. Then the keys on that partition are > used to set up swap and /home before the partition is unmounted, so the > keys are only exposed for 2-3 seconds per boot. > I'd prefer to not require any passwords to boot the system - I'm running a server and mythtv as well and if something goes down I'd rather it be back up on its own without me at the console. However, I did think of a potentially-elegant solution: 1. Create a new volume group for each swap partition. 2. Add the swap partitions to their volume groups. 3. Create one logical volume on each volume group. 4. Map the crytpo-loop devices to the LVM logical volumes. Then if device names change the LVM logic will find them and sort it all out. And there shouldn't be too much overhead running swap on top of LVM - my issue was with running swap on LVM on RAID-5 - which is a lot more overhead. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpLLEG4/rWKZmVWkRAu0kAKCYRulit1m/n/GVxT0W5ob9NORSqQCfbflv ffxVf4WlE77e4m339wvVrpU= =r1TI -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-23 13:53 ` Richard Freeman @ 2007-07-23 14:05 ` Neil Bothwick 2007-07-23 14:18 ` Richard Freeman 0 siblings, 1 reply; 18+ messages in thread From: Neil Bothwick @ 2007-07-23 14:05 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1618 bytes --] On Mon, 23 Jul 2007 09:53:12 -0400, Richard Freeman wrote: > > I keep my keys on an encrypted partition, /etc/conf.d/cryptfs prompts > > for the key for that partition at boot. Then the keys on that > > partition are used to set up swap and /home before the partition is > > unmounted, so the keys are only exposed for 2-3 seconds per boot. > I'd prefer to not require any passwords to boot the system - I'm running > a server and mythtv as well and if something goes down I'd rather it be > back up on its own without me at the console. Fair comment, I run this setup on a desktop and laptop. I do have an encrypted partition on a server, but it gets it's key over the network, and if the system will still work without that partition. I don't use encryption on my MythTV box because I don't record anything top secret ;-) > However, I did think of a potentially-elegant solution: > > 1. Create a new volume group for each swap partition. > 2. Add the swap partitions to their volume groups. > 3. Create one logical volume on each volume group. > 4. Map the crytpo-loop devices to the LVM logical volumes. > > Then if device names change the LVM logic will find them and sort it all > out. And there shouldn't be too much overhead running swap on top of > LVM - my issue was with running swap on LVM on RAID-5 - which is a lot > more overhead. That sounds a good plan, but why do you need multiple VGs? Why not put all the swap partitions in one VG then create one LV on each PV? -- Neil Bothwick Don't let your mind wander, it's too little to be let out alone. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-23 14:05 ` Neil Bothwick @ 2007-07-23 14:18 ` Richard Freeman 2007-07-23 14:55 ` Neil Bothwick 0 siblings, 1 reply; 18+ messages in thread From: Richard Freeman @ 2007-07-23 14:18 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1165 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Bothwick wrote: > > That sounds a good plan, but why do you need multiple VGs? Why not put > all the swap partitions in one VG then create one LV on each PV? > That would also work - having separate VGs helps ensure each swap device ends up on its own physical device. It could certainly be done using explicit device assignments when creating LVs. In any case, moving around swap devices is a piece of cake compared to moving around data, so it isn't a big deal either way. I wanted to separate two data LVs on separate physical devices and I did it exactly how you suggest keeping them in the same VG for future flexibility - moving LVs containing data is a real pain if they are in different VGs. With swap I just swapoff one device at a time making sure the total swap is sufficient at all times and the system moves around the data automatically... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpLjHG4/rWKZmVWkRAuCPAKC8dkmg7e+TILfKm1FXhWfacwUtiQCgwtb4 /FftfMGdja1OJGe0az0DYLc= =krpd -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-23 14:18 ` Richard Freeman @ 2007-07-23 14:55 ` Neil Bothwick 0 siblings, 0 replies; 18+ messages in thread From: Neil Bothwick @ 2007-07-23 14:55 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 631 bytes --] On Mon, 23 Jul 2007 10:18:48 -0400, Richard Freeman wrote: > > That sounds a good plan, but why do you need multiple VGs? Why not put > > all the swap partitions in one VG then create one LV on each PV? > That would also work - having separate VGs helps ensure each swap device > ends up on its own physical device. It could certainly be done using > explicit device assignments when creating LVs. That's what I was thinking of, it saves cluttering your system with unnecessary VGs. -- Neil Bothwick Ralph's Observation - It is a mistake to allow any mechanical object to realize that you are in a hurry. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 17:40 ` Richard Freeman 2007-07-20 18:31 ` Bernhard Auzinger 2007-07-20 18:35 ` Neil Bothwick @ 2007-07-20 19:17 ` Marek Wróbel 2 siblings, 0 replies; 18+ messages in thread From: Marek Wróbel @ 2007-07-20 19:17 UTC (permalink / raw To: gentoo-amd64 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-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 17:31 ` Richard Freeman 2007-07-20 17:40 ` Richard Freeman @ 2007-08-01 16:39 ` Bernhard Auzinger 2007-08-01 17:15 ` Richard Freeman 1 sibling, 1 reply; 18+ messages in thread From: Bernhard Auzinger @ 2007-08-01 16:39 UTC (permalink / raw To: gentoo-amd64 Am Freitag 20 Juli 2007 schrieb Richard Freeman: > 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... Just for the record. I decided to go LVM2 :). It runs since 10 days and I'm very happy with it. The setup was very quick and easy. For a few seconds I thought of buying a few more harddisks. Not because of the space, just because (vg/lv)extend excites me so much :). That stuff is cool. Regards Bernhard -- gentoo-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-08-01 16:39 ` Bernhard Auzinger @ 2007-08-01 17:15 ` Richard Freeman 0 siblings, 0 replies; 18+ messages in thread From: Richard Freeman @ 2007-08-01 17:15 UTC (permalink / raw To: gentoo-amd64 [-- Attachment #1: Type: text/plain, Size: 1713 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernhard Auzinger wrote: > > Just for the record. I decided to go LVM2 :). It runs since 10 days and I'm > very happy with it. The setup was very quick and easy. For a few seconds I > thought of buying a few more harddisks. Not because of the space, just > because (vg/lv)extend excites me so much :). That stuff is cool. > Hey - if you do get a few more drives be sure to check out mdadm... :) Linux software RAID is great - you can create an array, resize it, reshape it, add/remove drives, run a check - all while it is online I believe. Then you put lvm2 on top of the RAID to chop it into partitions. Right now I have 6 hard drives: 1 mirrored boot partition 1 mirrored root partition 1 RAID-5 striped across the remaining space on 3 drives 1 RAID-5 striped across most of the space on 3 other drives The two RAID-5 arrays are PVs in LVM2, and everything but root is under LVM2. I think the only things left on my 1GB root are /bin, /sbin, /etc, /lib, /lib64, and /root. My drives aren't all the same size so I'm still not 100% allocated - I could add more mirrored arrays to use some of the remaining space but I don't want to disrupt seeking on the two big RAID-5s. Works great - the only thing I would probably change is making /usr its own partition so that it doesn't need to be symlinked/bind-mounted. Some software doesn't like /usr as a symlink, although a bind-mount seems to work OK... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsL+zG4/rWKZmVWkRAp59AKC4NCiqT4kYGdpDxMq5pN+pSBk2IACgnQc0 QfGkOJXP0xRXhuSCIx5pynI= =fRDY -----END PGP SIGNATURE----- [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 4101 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* [gentoo-amd64] Re: 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 14:41 [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap Bernhard Auzinger 2007-07-20 15:13 ` Bob Sanders 2007-07-20 17:31 ` Richard Freeman @ 2007-07-20 18:41 ` Duncan 2007-07-20 18:47 ` [gentoo-amd64] " Bernhard Auzinger 3 siblings, 0 replies; 18+ messages in thread From: Duncan @ 2007-07-20 18:41 UTC (permalink / raw To: gentoo-amd64 Bernhard Auzinger <e0026053@student.tuwien.ac.at> posted 200707201641.30655.e0026053@student.tuwien.ac.at, excerpted below, on Fri, 20 Jul 2007 16:41:30 +0200: > 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? With four hard drives, particularly if they are near the same size (not an old 8 gig on the one end, and a new half terabyte on the other, with two in the middle), your best performance is likely to be in RAID. Here, I have four drives in RAID, using the kernel's own md RAID drivers, with RAID-1 for /boot, RAID-6 for my main system, and RAID-0 for stuff like /usr/portage, /usr/src, my ccache dir, and /tmp (altho with 8 gig memory, I actually have /tmp on a memory based tmpfs). Swap is also setup as effectively RAID-0. Note that RAID using both master and slave on IDE/PATA isn't all that efficient, however. Here, my hard drives are all SATA, tho I'm still using PATA CD/DVD drives (but only one on each channel master, not master and slave). Of course, SCSI is its own discussion. If your drives are different size but all say 80 gig or better, you could still do a RAID-0 for speed and put /tmp, swap and the like on that (you don't want to put anything important on RAID-0, since if one drives dies, you lose everything on the RAID-0, but it's fast, so is good for temp stuff like swap and /tmp, and stuff you can download off the net again easily if necessary, like the gentoo/portage tree), especially if the drives aren't installed as IDE/PATA both master and slave. If one or more of the drives are older and below about 80 gig, chances are it's slow enough it'd be bottlenecking the others anyway, so don't bother. Alternatively, you want to make sure as much as possible, that stuff accessed at the same time is on different disks. Generally, that's the same stuff as the candidates for RAID-0 above, swap, /tmp (and /var/tmp), ccache, and the gentoo/portage tree, particularly if you tend to do emerges in the background while continuing to work on other stuff. The caveat for swap is that the newer and therefore larger drives tend to be faster, and it's them that generally have the main system on them already (unless you have your largest drive as a dedicated media drive as some people do). It's often most convenient to try swap on the old/slow drive, but of course, that can be counter-productive. Still, it depends. It may still be faster on it, than having the new/fast drive trying to handle both system and swap at the same time, even if the swap drive /is/ your old/slow one. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap 2007-07-20 14:41 [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap Bernhard Auzinger ` (2 preceding siblings ...) 2007-07-20 18:41 ` [gentoo-amd64] " Duncan @ 2007-07-20 18:47 ` Bernhard Auzinger 3 siblings, 0 replies; 18+ messages in thread From: Bernhard Auzinger @ 2007-07-20 18:47 UTC (permalink / raw To: gentoo-amd64 > 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-amd64@gentoo.org mailing list ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2007-08-01 17:17 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-20 14:41 [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap Bernhard Auzinger 2007-07-20 15:13 ` Bob Sanders 2007-07-20 17:10 ` Beso 2007-07-20 17:31 ` Richard Freeman 2007-07-20 17:40 ` Richard Freeman 2007-07-20 18:31 ` Bernhard Auzinger 2007-07-20 18:35 ` Neil Bothwick 2007-07-20 19:37 ` Richard Freeman 2007-07-20 19:49 ` Neil Bothwick 2007-07-23 13:53 ` Richard Freeman 2007-07-23 14:05 ` Neil Bothwick 2007-07-23 14:18 ` Richard Freeman 2007-07-23 14:55 ` Neil Bothwick 2007-07-20 19:17 ` Marek Wróbel 2007-08-01 16:39 ` Bernhard Auzinger 2007-08-01 17:15 ` Richard Freeman 2007-07-20 18:41 ` [gentoo-amd64] " Duncan 2007-07-20 18:47 ` [gentoo-amd64] " Bernhard Auzinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox