Thanks for the various answers and suggestions. To answer the questions: > Why use GFS in a read-heavy environment? Why not use plain old NFS? It is neither READ nor WRITE heavy. The app binaries will be loaded and stay there till the end of the day. Do not want to go NFS route since the NFS server is single point of failure.
> And what is the state of cachefs? If it's production, most definitely > NFS + cachefs over GFS. Haven't looked into NFS + cachefs. > GFS is comparable to ext3 performance-wise, a bit slower in some types > of operation. GFS2 is a bit better than ext3. I'm actually thinking of going GFS2. The bottom line is, I want to have only ONE app binary partition so that: 1. I'm 100% sure the servers are always running the same code. 2. Less maintenance; just upgrade the app files once when there is a new version of app to be installed. 3. No single point of failure - Can't afford the servers hanging due to NFS server going south. 4. Only ONE partition to back up/restore. Bottom line, I'm trying to come up with a robust and low maintenance design. If there are better solutions than GS2 based cluster file system I'm all ears and flexible. Thanks in advance. Win > Hi folks, > > I'm looking into creating a common GFS partition (cluster file system) > where my app binary files will reside. There will be very little file > updates on a daily basis and will be mounted/shared from less than 10 > servers. I would like to hear the opinion of real world production > users regards to stability, performance etc. Thanks in advance. > > Cheers, > Win _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
