I need a cluster of nodes to have read and write access to a scalable and common pool of storage connected to an FC SAN. The entire pool of storage must appear as one single file system to the cluster nodes. So far so good. GFS fits. But...
The application running on each node is partitioned in such a way that at any given moment, only one node will need read / write access to a directory and its descendant file tree.
For example, let's say the file system is called "/big" and it has directories "a", "b", ... "z". Let's say that I have cluster node "1", "2", and "3". When node 1 needs access to "/big/a", the other nodes "2" and "3", won't need access to "/big/a". Those nodes will be reading and writing in to "/big/b" or "/big/c" or something else. In general, "/big/a" and other directories could have several million files.
A few minutes to hours later, node 2 might take over the read / write responsibilities for "/big/a", and node 1 might move over to "/big/b", etc.
From reading the GFS documentation, it certainly appears that a standard GFS with locking (single or redundant servers) would work in this situation. But, I would like to avoid designating any single or multiple servers as lock servers. This is because the cluster is very dynamic. Nodes can constantly be added or removed, and the system administration environment isn't conducive for designating lock servers and protecting them. Besides, I am wondering why the lock servers should work so hard to maintain all the locks on the millions of files when I know 100% that no other node is going to access the files simultaneously.
So, my question is: Can I simply use LOCK_NOLOCK in this situation and avoid any lock server? Maybe the answer is no because the documentation warns "Do not allow multiple nodes to mount the same file system while LOCK_NOLOCK is used. Doing so causes one or more nodes to panic their kernels, and may cause file system corruption".
I am still asking the question because of this partitioned file system access characteristic of my application. Is this warning still valid if I can guarantee that no two files or directories will be accessed by two different nodes simultaneously? If I can't do LOCK_NOLOCK, is there any other idea I can use here?
Thanks for your time
-- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
