On 01/27/09 02:21, Keith Freedman wrote: > At 10:36 AM 1/26/2009, Prabhu Ramachandran wrote: >> Are you saying I can't use the local files on machine A (even if I am >> not touching any files on B) when the network is down even though all I >> am doing is reading and perhaps writing locally on A? That could be a >> bit of a problem in my case since I usually keep any local builds on the >> partitions I'd like to share. There could be other problems when one >> machine is down for maintenance for example (or the disk crashes). > > I'm not saying that. you can use the files on the local machine. and > it will, it'll just have to wait for network timeouts to decode that > machine B is down before it continues. OK that is consistent with what I had in mind. > The problem would be if the network between A and B is down. you update > files on A (say run a build), and simultaneously update files on B (run > a build there too), then the network comes back up, the same files might > have changed on both A & B at the same time, and this would cause a > split-brain. > > but if you always only update on A, then it doesn't matter. when the > network is down, B will have local access to the version of files that > were correct as of the last time they were in sync, but it will still > serve them. I think this should work fine for me. >> The attachment is scrubbed which makes it a pain to get from there. I >> enclose the relevant parts below. Many thanks. > > I dont see any problems with your config. > other than, if your network connection is very sporadic, then you'll be > caught often by waiting for timeouts which will make things seem slower. Network connection isn't usually a problem but when the network does go it could be gone for a while. In the worst case could I temporarily disable the replicate/AFR feature? > What you seem to want is for gluster to serve local files instantly, but > it can't because in HA mode, it needs to know that either the replica is > down, or that is has the most current version. if your network is > spotty, then it will constanly be waiting to decide that the network is > down before continuing on, that's likely the concern that was raised > earlier. > > but if it's more likely that the network will be down for a while then > up for a while, then it's not a big deal and you should be just fine. I could use this option: read-subvolume (default: none) This might actually be the best solution in this case. I could have each client only read files from the local subvolume and sync the writes when that happens. There will be a problem with any writes though but I might just have to live with that or disable AFR for a while. Thanks for all the clarifications and your patience! cheers, prabhu
