Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 recently formatted a 20TB array as XFS. For file transfers < 10G performance is fantastic. However once I exceed 10G disk I/O decays logarithmically. I have the journal on the same disk. When I look at the disk IO usage, I see that jbd2flush is using nearly all disk IO. How can I resolve this? (Any way to do it w/o removing the data?) I am running Ubuntu 10.10. Thank you.

share|improve this question
How big and how many log buggers did you create when you made the filesystem? – Decado Mar 29 '11 at 6:30
Is there a way I can check? I don't recall. – ensnare Mar 29 '11 at 6:31
xfs-info should do it. – Decado Mar 29 '11 at 6:49
Also, how many disks in the array and in what kind of raid array, and hardware or software controller? – Decado Mar 29 '11 at 6:50
8 disks hardware controlled. Doubtful it's the controller -- when I had 8x1TB drives in RAID5 formatted in ext4 I didn't have this problem. Only after my recent re-format with XFS. – ensnare Mar 29 '11 at 7:26

The journal is usually never the performance problem except for small random write IO, as the log is a circular buffer that is access sequentially as the log just gets appended.

How much memory does the system have? Whate are the watermarks on the pdflush side of things?

Can you produce a throughput diagram ie plot some of the columns of iostat -x -k 1 with gnuplot or something like that for the <10GB and for > 10GB cases?

share|improve this answer
It looks like the RAM on the system is getting eaten up. I have 4GB which may not be sufficient for a 20TB array. When I do free -m I see that the system starts eating away at swap for files < 10GB. Will put in more RAM to test. Do you happen to know the minimum requirement for a 20TB XFS array? Thanks. – ensnare Mar 29 '11 at 18:58
it may even bee "too" much RAM so that pdflush is keeping too much dirty memory that needs to be flushed frequently so that your IO suffers from very spiky throughput. – pfo Mar 29 '11 at 19:34
Interesting -- Any way to check exactly what's going on? – ensnare Mar 29 '11 at 21:39

To reduce contention under high load, I would put the journal on a separate disk. Easiest would have been one disk from the array itself but probably you cannot do this anymore without backup restore. Setting a dedicated log device is explained in the tune2fs(8) manpage under the option -J.

share|improve this answer
Is there a way to move the journal without re-formatting the array? Thanks. – ensnare Mar 29 '11 at 18:58

Is your XFS file system aligned to stripe size? This may not be directly related to your performance issue but it definitely improves performance. Please check this thread for some general ideas and samples.

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.