Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, Dec 6, 2013 at 10:56 AM, Richard Pieri <richard.pieri at gmail.com>wrote: > Greg Rundlett (freephile) wrote: > >> I think it's pretty obvious why it's not performing: user home >> directories >> (where developers compile) should not be NFS mounted. [1] The source >> repositories themselves should also not be stored on a NAS. >> > > Neither of these statements are true. > > User home directories is one of the best things you can do with NFS. It's > what it was designed to do after all. > User home directories should be NFS/NAS, yes. But their checkout / build area need not be in Home filesystem. Even if it's symlinked or temporarily mounted there. Your performance problem is simple. Every Unix and Linux vendor in the > world these days defaults to setting NFS write caching off. This makes NFS > performance excruciatingly poor for lots of small writes, the kind of > behavior you see when someone compiles lots of little C files. Enable write > caching on the home directories and watch your performance improve > dramatically. > There are many other performance traps in NFS/NAS too. That is one. > Storing repositories on NAS has less to do with yes/no and more to do with > how the code servers -- the servers that users check out and in through -- > talk to NAS and what you've done (or not done) to optimize that performance > Having the repository on NAS can work, although i'd prefer it behind a real server than trust multiple writers to update it concurrently correctly. -- Bill @n1vux bill.n1vux at gmail.com
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |