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

My Ubuntu backup server was recently upgraded in storage space to a RAID 10 array... now it consists of 8T of raw drive space which was before 2T of space.

But I have been having trouble when it actually goes into production and starts backing up my main file server. It would always go into a degraded state when the rotation took place.

I noted that some of my scripts copy pretty big trees with cp -a... since i've replaced all cp commands with rsync... for a little more reliability :)

However, digging upon the subject of ext4 I discovered that journal entries are left unsatisfied too long (so it appears) so I've moved back to ext3.

I am considering creating a RAID 1 partition by using a small partition on drive and a ramdisk as the actual journal which should ensure speed for journal response and also ensure that the data is not lost upon reboot.

What are your thoughts?

share|improve this question

Using a RAM-disk and a HDD together in a RAID1 would not do what you think it would.

From the Linux RAID howto:

Linux MD RAID-1 (mirroring) write performance:

Must wait for the write to occur to all of the disks in the mirror. This is because a copy of the data must be written to each of the disks in the mirror. Thus, performance will be roughly equal to the write performance to a single disk.

So placing a filesystem journal on such a device would not improve your performance at all (since the system would wait for the write to complete on all members). Also, you should keep in mind that the journal is actually the most crucial part of the filesystem in the event of a system crash or power outage - it ensures filesystem consistency in these border cases.

If you need higher write performance for your journal, consider placing it on a SSD RAID-1 device instead.

It would be even better to increase your array's performance by using a BBWC-backed RAID controller where you could activate the write cache without risking your data's consistency.

share|improve this answer
Yes, I considered SSD... However, SSD drives actually have caps on writes which will lead to sectors being marked bad. In a high traffic area like the journal this cap would likely be quickly reached. – donjon Feb 6 '12 at 21:47
@donjon if you are too concerned about wear, there are DRAM-backed SSDs (PCIe as well as SATA variants exist). But as I stated, using a decent storage back-end performant enough for the task should be your first route. – the-wabbit Feb 6 '12 at 22:12
@donjon That's only true of physical sectors on the drive, which is totally irrelevant because the system only has access to logical sectors. You can use an SSD, reaching the write cap on a physical sector is irrelevant. – David Schwartz Feb 7 '12 at 2:05

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.