There has been some confusion in the field of late around the node unavailability conditions under which Isilon OneFS will place an entire cluster, or individual node pool, into read-only mode.

If an Isilon cluster does not have quorum (ie. at least N/2 + 1 nodes in the N-node cluster are up), it will automatically be marked as read-only. In this state, it will not accept write requests from any protocols, regardless of any particular node pool membership issues.

However, if a cluster has quorum but a given node pool ends up having only two nodes online due to unavailability of a node, that node pool will still be writable. Note: The node pool couldn’t be provisioned this way, and would have had to have started out with a minimum of three nodes. Furthermore, if this node pool goes down to just one node online, it won't accept writes, but you will still be able read from it

Depending on the protection policy that was used to write the data, it’s not necessarily the case that all data stored on that node pool will be readable with only one node available. If, for example, the node pool originally comprised three nodes and the protection policy was set to +2n, everything will be readable. But, if the node pool contained more than three nodes originally and only one is up, there will be some data which is unavailable.

For further information on node pools and their relation to the OneFS storage heirachy, and OneFS filesystem protection, please refer to the following blog posts:

OneFS SmartPools - Storage Pools Taxonomy


Exploring OneFS Storage Protection Overhead