Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an option to create a single raid volume and partition it in the OS, or create multiple raid volumes (one for each partition)?

  1. What are the performance or access time differences between two?
  2. Are they handled differently? If so, what are the pros and cons of each?
share|improve this question
How many physical disks are involved? Do you have a need to have them partitioned into separate spaces? What are the goals of your RAID -- performance or redundancy? (Basic answer -- to get a useful response you need to give more information.) – Michael McNally Mar 19 '13 at 18:33
I currently have 4 drives (2x1.5 and 2x2) and plan to add two 3TB. The only reason for partitioning that I have is to separate media storage from misc files. As for media files I will say performance. For misc files I would prefer performance and redundancy (raid 5 maybe but will be limited to minimum drive size of 1.5TB with current setup) – Mar 19 '13 at 18:42
up vote 2 down vote accepted

The answer to this is entirely situation-dependent.
You need to assess your particular environment and your particular needs to make a decision on RAID volume layout and partitioning schemes.

The difference between the two ways of handling this comes down to "one RAID volume or several".

With one RAID volume you have simplicity - you are partitioning one big block of space.
That simplicity comes at the cost of performance: all of your requests are hitting one RAID volume, so as you scale up and add more requests you get closer to saturating the available bandwidth in that volume.
There's no distinction between requests, so if your machine is swapping heavily and trying to read data out of a database at the same time those two tasks will be trying to hit the same pool of disk bandwidth, and can cause resource contention which ultimately reduces performance.

Multiple RAID volumes allow you to split up "types of requests" across different disk groups, and possibly different RAID controllers, to maximize available bandwidth.
Using our "Swap versus Database" fight from above, if the swap space and the database are on different RAID volumes they won't interfere with each other: The swap requests are hitting the swap volume's disks, and the DB requests are hitting the DB volume's disks. This eliminates the resource contention, and allows for better performance.
The performance comes at a cost too -- you lose the simplicity of a "one big block of space" design, and have to think more carefully about assigning disks to RAID volumes to ensure you don't run out of space. You may also need to buy more disks in order to properly structure this sort of environment.

Three potentially illustrative examples:

Basic "Front-End" Server

For a simple "front-end" server, something that just runs a web site and makes all of its requests to back-end systems/databases, a single RAID partitioned by the OS usually makes sense.

You aren't going to be storing data on this box, and the read/write performance is usually not critical since the disk I/O volume is low and your application code will usually fit in RAM/cache - all you want is for the system to keep working if you lose a disk.

File Server ("File Dump")

A file server (or "File Dump") can often be broken up into two RAID volumes:

  • The OS stuff
  • The File Storage

In this case the "OS Stuff" will be subdivided the same way as above, but the "File Storage" RAID volume may be one big partition, or multiple partitions.
One reason for doing this could be to provide different RAID levels (RAID 1 for the OS stuff, RAID 0 for the data (if you don't care about redundancy and just need space), possibly across different classes of drive (fast file storage, slower/cheaper OS disks).

Database Server

Database servers are the complete opposite end of the spectrum from the "Front-End" server.
Typically you break them up with multiple RAID volumes for:

  • The static OS files, and possibly OS log files
  • Swap space, though you hope to never use it
  • Database table space
    • Possibly multiple tablespaces, if we're talking about high volume
  • Database transaction log space
  • Database backups (dumps)

The first of these may be further subdivided by the OS, but the remainder are usually partitions, on top of discrete, dedicated RAID arrays.

Here the RAID volume layout (and partitioning) are really dictated by database performance factors, and you'll typically follow the recommendations of your database vendor (or DBAs), which will focus on multiple spindles (sometimes on multiple controllers) to maximize disk throughput.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.