I have a server with 3 146GB hard drives. I need to load it with Linux, for it to be a LAMP server, and possibly host a few samba shares. I was thinking of just RAID5'ing the 3 drives and have everything on one big drive. what would you suggest?

Yep, I agree, if you use LVM and leave some free extents you can easily increase a partition later as well,

cheers

I was thinking of just using the RAID5 through the BIOS (not software RAID) and no LVM. for what this server is going to do, i'm never going to run out of space.

Hi,
Partition schemes for a server are not typical. I would suggest that you look at expected loads, system allocation along with user needs. Your security needs or requirements should be taken into account. You could do a search here on LQ as this subject has been covered so many times.

I tried looking for partitioning for a LAMP server but didn't see anything specifically, guess i missed it.

or maybe i should mirror with an online spare since it won't be hit too hard?

Hi,
Server partition results. You can polish with different search key words. Your 'LAMP' needs may be different than others but a LAMP_wiki may aid you via the external links.

ok, thanks Gary

1)if you have no exact plan (no special needs), then the best choice is to make a single partitions for all
2)hardware raid has one big minus: when your controller fails you need exactly the same controller with exactly the same settings to get back your data. On the other side hardware controller is a little faster - choose what you need more: speed or ease of management.
3a)create raid5 is good idea when you have spare drive. In case of failure of one drive the data will be recomputed using checksums - it 'll cause significant slowdown. When you have spare the system will be slow only while creating neccesary data on it, when you have no spare - the system may get completely unusable even under intermediate loads.
3b)in case of mirror the spare is a waste of drive (in my opinion). As for me it's better to keep it single and use for non-critical data: logs, swap, caches, temporary files etc. In case of failure you can simply remove it - the mountpoints will be empty and the system will use the space on the mirror to store all this stuff - until you replace your drive

I disagree with that. Nowadays there are multi gigz HDDs and to have one big root on that beast is complete disaster. Imagine you have to fsck this root, you will be waiting for ages, I promise!
Much better idea is to have a moderate root (say, 10 to 20 gigz if all the stuff is here, I mean /usr,/var, etc. or even 1g if all the stuff is not on this partition). And I suggest to have all other (user) data on /home, /export/home or any name you like. Trust me, with a moderate root you will get you system up quickly regardless of other pending issues you may have with the data FSs.
And yet, do not make a separate /boot if you do not have a strong motivation to do so, e.g. root on LVM and so on.
Remember, /boot used do not have any salvage utilities, compare with root (/sbin/e2fsck and so on). That's a trap for cubs.
Also, this hist is only valid for Linux, not for other kins like freebsd or solaris.

Agree with issues while RAID controler replacement, what a headache!
Disagree about "speed" of HW raid. It depends upon many factors.
It is funny to compare say i960 with 66MHz bus (a typical CPU on HW raid) and even a desktop having today's pci-x/pci-e buses and >2ghz CPU.
In my practice, VxVM runs well on par with built-in HW raids.
Again, linux sw raid was twice or even more faster than a nibbled Intel low-cost (about 250$) HW RAID despite all salesmen claims. Though an expensive 700$ HW RAID was run very well as fast as free linux sw raid .
A spare drive for mirror is not a waste if you:
a) cannot get in quickly and swap that bad drive (remote sites)
b) are not sure about your drives
c) have a lot of mirrors, think about MTBF and normal event probability distribution.
Swap is not a "non-critical data". Its mishandling could cause a system panic.
If you have a lot of gigz and do not want a suspend, maybe it's better to turn it off completely? I said this because Linux is not so aggressive to pull to swap all the stuff as Solaris or FreeBSD, it feels good even with no cache at all if you have a sufficient RAM for you tasks, believe me.
In case of RAID5 to have a spare drive is a MUST. Otherwise you'll be lost.
Though generally I agree with your common sense idea to allocate thrid drive for non-critical data like a squid cache.
Yet another advantage of linux sw raid: adding a drive to mirror is easy and straightforward so it can be done just when needed.

I do have one ~2Tb raid5 with reiserfs. The speed of normal boot and boot after reset or power failure differs only when raid resynchonization happens.

I agree: when you can't quickly reach your server then all these things should be taken into account.

ok guys, thanks.

here's what i ended up doing, although a lot of the drive sizes are .1GB off (i wanted 4 and 6GB, not 3.9 and 5.9)

Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.0G 240M 2.6G 9% /
/dev/sda10 66G 180M 62G 1% /data1
/dev/sda9 3.0G 69M 2.7G 3% /home
/dev/sda8 3.9G 73M 3.7G 2% /tmp
/dev/sda7 3.9G 110M 3.6G 3% /var
/dev/sda6 5.9G 1.3G 4.3G 24% /usr
/dev/sda5 47G 181M 44G 1% /opt
/dev/sda1 122M 11M 105M 10% /boot
tmpfs 1014M 0 1014M 0% /dev/shm


Disk /dev/sda: 146.5 GB, 146557370368 bytes
255 heads, 63 sectors/track, 17817 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 16 128488+ 83 Linux
/dev/sda2 17 408 3148740 83 Linux
/dev/sda3 409 539 1052257+ 82 Linux swap / Solaris
/dev/sda4 540 17817 138785535 5 Extended
/dev/sda5 540 6805 50331613+ 83 Linux
/dev/sda6 6806 7588 6289416 83 Linux
/dev/sda7 7589 8110 4192933+ 83 Linux
/dev/sda8 8111 8632 4192933+ 83 Linux
/dev/sda9 8633 9024 3148708+ 83 Linux
/dev/sda10 9025 17817 70629741 83 Linux