Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote -1 down vote favorite

I'm looking for a File System that handle intensive IO so NFS can serve mounting /home for multiple(<50) users.

Actually we do ext3 over NFS, but perfs are not good.

I Already read this1 (NFS under VMware) and this2 (ext4 instead of ext3 ). but it does not really answer my question.

share|improve this question
6  
How did you come to the conclusion that it's the server's filesystem that is the bottleneck? – Mat Nov 29 '12 at 19:16
In addition to @Mat's comment. What will these users be doing? Secondly have you used Bonnie to benchmark various file systems for the intended use? – Karlson Nov 29 '12 at 19:35
Just to add to Mat's insightful comment: your NFS link is unlikely to be better than 1 Gigabit Ethernet, which at its very best is slower than a lone desktop hard drive. If you're RAIDing together many hard drives, and using high-speed drives and a decent RAID system, as I surely hope you are given the application, you have far more I/O ability than needed to saturate a gig-E link. So another way of asking Mat's question is, how have you eliminated the Ethernet/NFS link as the bottleneck? – Warren Young Nov 29 '12 at 21:24
Thank you folks for your comments. @Karlson no, i didn't make any benchmarks, and the users main activity is compiling (linux kernel for example) on another powerfull machine but mounting the sources throught NFS reduce the speed of compiling. – Zskdan Nov 29 '12 at 22:31
1  
@Mat, I did not conclude that the filesystem is the bottleneck, I'm just wondering if i can boost perfermance by using other suitable FS than ext3. – Zskdan Nov 29 '12 at 22:34
show 7 more comments

closed as not a real question by Gilles, Renan, Mat, jasonwryan, jw013 Nov 30 '12 at 18:24

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.

3 Answers

up vote 0 down vote

How is the performance quantitatively, and what is unacceptable?

If you are not satisfied with the performance of NFS, the first place to look is your network. The second place to look is NFS. The difference in performance between ext3 and ext4 will probably not be enough to justify the change (that said, I usually use ext4).

I would recommend analyzing the network traffic and infrastructure, the hardware and operating environment, and profiling the applications accessing the NFS shares. All of these factors can have an impact on how options should be set in the network, NFS and even kernel configurations.

See http://nfs.sourceforge.net/nfs-howto/ar01s05.html for a guide to optimization on Linux.

share|improve this answer
up vote 0 down vote

It has been my experience that home directories don't require that much I/O, and most of that will be read access. The fact that you are mounting home directories also cuts down on file contention as each user has their own directory and files.

I have worked with NFS mounted home directories where I had processes generating files on multiple servers and never noticed a problem.

If you could explain why you think your particular setup will generate heavy I/O, it may be easier to provide assistance.

As others have noted, the network is a good place to start. What kind of bandwidth do you have, and how heavily is it used? What kind of problems do you have, slow read and/or slow write? Problems in one direction only would have me looking for a duplex mismatch.

nfsstat is your friend. Use it to see how busy your NFS is. Also look at running sar in the background to see how busy your disks are.

Consider installing a monitoring process like munin that will give easy access to a lot of useful load statistics.

share|improve this answer
It has been my experience that home directories don't require that much I/O, and most of that will be read access - For an average user you're right. For developers it's not the case. Heavy builds which OP is indicated the intended use could produce heave I/O and performance problems (spoken from experience) – Karlson Nov 30 '12 at 13:58
@Karlson NFS is not a good platform for builds, especially the tempfiles that can be generated. I have had a single build cause problems on a production system. There are alternative mechanism to having developers to frequent clean builds on their environment. I've worked with a large team successfully using NFS for their home directories. – BillThor Nov 30 '12 at 15:06
Never said it was. And don't think that it is but not my call on the architecture see OP's reply to me – Karlson Nov 30 '12 at 15:20
up vote 0 down vote

Before looking at the underlying filesystem I would suggest doing actual performance measurements on the NFS shares you create. For example may be it's better for you to make this share async. Or play with block sizes to make them the size of the block of your filesystem. Make sure that your network buffers are sufficient to allow for possible bursts of traffic when everyone writes at the same time.

All in all I would suggest looking at NFS performance tuning documentation starting with this one before you even attempt switching the filesystem.

A couple of years ago I Bonnie tested most of the available filesystems on RHEL4, RHEL5, Ubuntu 8.04 and 10.04 and found that for my purposes ReiserFS performed best. I think that you should do the same.

share|improve this answer

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