Chapter 11. Using GNBD

GNBD (Global Network Block Device) provides block-level storage access over an Ethernet LAN. GNBD components run as a client in a GFS node and as a server in a GNBD server node. A GNBD server node exports block-level storage from its local storage (either directly attached storage or SAN storage) to a GFS node.

This chapter describes how to use GNBD with Red Hat GFS and consists of the following sections:

11.1. GNBD Driver and Command Usage

The Global Network Block Device (GNBD) driver allows a node to export its local storage as a GNBD over a network so that other nodes on the network can share the storage. Client nodes importing the GNBD use it like any other block device. Importing a GNBD on multiple clients forms a shared storage configuration through which GFS can be used.

The GNBD driver is implemented through the following client and server kernel modules.

Two user commands are available to configure GNBD:

11.1.1. Exporting a GNBD from a Server

The gnbd_serv.o kernel module must be loaded on a node before it can export storage as a GNBD. Once local storage has been identified to be exported, the gnbd_export command is used to export it.


When configured for GNBD multipath, a GNBD server (a server that is exporting a GNBD) ignores Linux page caching. Caching is ignored to ensure data integrity when using GNBD multipath. (By default, the gnbd_export command exports with caching turned off.)


A server should not import the GNBDs to use them as a client would. If a server exports the devices uncached, they may also be used by ccsd and gfs. Usage

gnbd_export -d pathname -e gnbdname [-c]]


Specifies a storage device to export.


Specifies an arbitrary name selected for the GNBD. It is used as the device name on GNBD clients. This name must be unique among all GNBDs exported in the network.


Export the device as read-only.


If a GNBD server that is exporting CCS files is also exporting GNBDs in multipath mode, it must export the CCS files as read-only. Under those circumstances, a GNBD client cannot use ccs_tool to update its copy of the CCS files. Instead, the CCS files must be updated on a node where the CCS files are stored locally or on FC-attached storage.


Enable caching. Reads from the exported GNBD and takes advantage of the Linux page cache.

By default, the gnbd_export command does not enable caching.


For GNBD multipath, you must not specify the -c option. All GNBDs that are part of the pool must run with caching disabled. Pool, the GFS volume manager, does not check for caching being disabled; therefore, data corruption will occur if the GNBD devices are run with caching enabled.


If you have been using GFS 5.2 or earlier and do not want to change your GNBD setup you should specify the -c option. Before GFS Release 5.2.1, Linux caching was enabled by default for gnbd_export. If the -c option is not specified, GNBD runs with a noticeable performance decrease. Also, if the -c option is not specified, the exported GNBD runs in timeout mode, using the default timeout value (the -t option). For more information about the gnbd_export command and its options, see the gnbd_export man page. Examples

This example is for a GNBD server configured with GNBD multipath. It exports device /dev/sdc2 as GNBD gamma. Cache is disabled by default.

gnbd_export -d /dev/sdc2 -e gamma

This example is for a GNBD server not configured with GNBD multipath. It exports device /dev/sdb2 as GNBD delta with cache enabled.

gnbd_export -d /dev/sdb1 -e delta -c

11.1.2. Importing a GNBD on a Client

The gnbd.o kernel module must be loaded on a node before it can import GNBDs. When GNBDs are imported, device nodes are created for them in /dev/gnbd/ with the name assigned when they were exported. Usage

gnbd_import -i Server


Specifies a GNBD server by hostname or IP address from which to import GNBDs. All GNBDs exported from the server are imported on the client running this command. Example

This example imports all GNBDs from the server named nodeA.

gnbd_import -i nodeA