Joshua, If you must, you could still copy the vol VOLNAME-fuse.vol file and mount that way, but keep in mind this will mean that your volume is no longer elastic so adding and removing bricks cannot be done on-line. -Jacob -----Original Message----- From: Joshua Baker-LePain [mailto:jlb17 at duke.edu] Sent: Thursday, December 09, 2010 2:39 PM To: Jacob Shucart Cc: 'gluster-users' Subject: RE: GlusterFS 3.1.1 - local volume mount On Thu, 9 Dec 2010 at 4:29pm, Jacob Shucart wrote > That is correct. If at the time you try to mount the volume the server is > down, then you won't be able to mount the volume in the first place. If > this is a concern, you can set up something like ucarp to handle IP > failover so your mount command will work, but usually mounting is > something that is not done frequently, right? Or you could have a round > robin DNS entry that points to all of your storage nodes so that your > mount command is essentially hitting a different server each time. I'll have several hundred clients which reboot at random times (cluster nodes which get kernel updates and then reboot when the jobs running on them have finished, as well as the usual hardware maintenance on random nodes), so it's better not having to worry whether or not a particular gluster server is down at any point in time. It's also a bit of a bummer that, for this particular situation, the deprecated volume file approach is more robust than the recommended one. I do understand that there are other advantages, though. Since I don't do DNS on the cluster, I'll have to look into ucarp. Thanks for the info. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF
