http://www.linux-mag.com/id/7118Network Block Devices: Using Hardware Over a NetworkIn cases where NFS or SMB/CIFS won’t fit the needs of your Linux network, Network Block Devices (NBDs) may provide superior performance over traditional network filesystems. Most Linux administrators today are familiar with protocols such as the Network File System (NFS) and the Server Message Block/Common Internet File System (SMB/CIFS, the protocol used by Samba). These protocols enable you to share filesystems across a network — the Linux computer sitting on your desk can access files stored on another Linux system, a Windows computer, or whatnot across the office (or on the other side of the planet!). While NFS, SMB/CIFS, and similar protocols are handy, they aren’t always ideally suited to what you need to do. One obscure Linux tool can sometimes help on this score: Network block devices (NBDs). This tool is a way to enable one computer to provide another computer with direct low-level access to block device hardware. (Block devices exchange data in fixed-size multi-byte blocks, whereas character devices communicate in byte-size chunks. Disks, including hard disks, floppy disks, and CD-ROM/DVD drives, are the most common block devices.) Why Use NBDs? Why would you want to use an NBD rather than a more common file-sharing protocol? Several scenarios come to mind:
You may be able to find workarounds or superior alternatives to NBDs in many of these cases. For instance, you could upgrade your server’s low-level disk utilities or expand the disk space on the client. Sometimes, though, NBDs may make more sense. You’ll need to be the judge of which is true in your case. You should be aware that NBDs have their limitations, too. The most important of these is that providing read/write access to NBDs to more than one client is extremely dangerous. Ordinarily, you’ll either limit the NBD access to a single client or use NBDs to provide read-only access to data (as is possible for a diskless workstation’s root filesystem). NBDs can also encounter deadlock conditions, particularly if you try to access the NBD from the server. If you need to update the NBD’s partition from the server, you should do so directly — and when no client is using it, particularly if read/write client access is desirable. Obtaining NBD Software NBD software for Linux includes three components:
The user-space software can be obtained from
http://sourceforge.net/projects/nbd. The
The result will be the installation of the Your NBD client requires kernel support to use NBDs, but the kernel support is not needed on the server. To add this support, you must compile it into your kernel (or as a module). The module is called nbd, so you can look for it on your system before you recompile your kernel. (On my systems, it’s stored in /lib/modules/version/kernel/drivers/block, where version is the kernel version number.) Completely describing the process of recompiling your kernel is beyond the scope of this column. Assuming you know how to do it, you can find the NBD option under Device Drivers -> Block Devices, as Network block device support. Activate this option (either compiling it directly into the kernel or building it as a module) and recompile your kernel. (In some cases, recompiling just your kernel modules will do.) You’ll also need to install your kernel modules, and probably the kernel. If you changed the kernel proper, you may need to modify your LILO or GRUB configuration and reboot. Preparing an NBD Server The first step in preparing an NBD server is to set aside a block device for use by the server. Typically, this will be a hard disk partition, although it could be a logical volume manager (LVM) volume, redundant array of independent disks (RAID) device, CD-ROM/DVD-ROM drive, or some other block device. You may also create a regular file and export it as a block device. This approach is similar to using a loopback device locally, but you give a remote system access to the file as if it were a block device. This can be handy if you want to provide clients with access to a variety of image files (CD-ROM images, say). Depending on how you want to use the NBD, you might want or need to create a filesystem on the device and populate it with files beforehand. This would be necessary, for instance, if you intend to use the NBD as a read-only root filesystem for diskless network clients. In other cases, you might leave the preparation of the storage space to the client. This would be necessary if the server doesn’t support the filesystem or other low-level format the client uses, as for instance when using a Windows NBD server. Whether or not you prepare the NBD storage space using the server computer, you should be sure to never access the NBD space using the server when the clients do so! In the case of read/write client access, having two clients write to a filesystem simultaneously is almost certain to produce data corruption. In the case of read-only access, unexpected writes might confuse the client. You’ll need to be careful about how you prepare and use your disk space on the server side to avoid such problems. With the disk space prepared, you can run the NBD server: # nbd-server 2000 /dev/sdb1 This command exports /dev/sdb1 using port 2000. Note that
the device filename must use an absolute path, not a relative path. The
version of NBD I tested issues a warning message about being unable to
open its config file. This message seems to be harmless, so you can
ignore it. In principle, you can run
The On the plus side, it’s a way around the danger associated with providing write access to multiple clients; each client gets a unique diff file on the server, so each client can safely write to the “shared” file without damaging other clients’ files. As an example of some of # nbd-server 2000 /dev/sdb1 -r -l /etc/nbd.allow This command provides read-only access to /dev/sdb1 to those clients whose IP addresses appear in /etc/nbd.allow. Preparing a Server Configuration File Instead of specifying options on the command line, you can create an
NBD server configuration file. This file consists of named sections,
each section name enclosed in square brackets ( Listing One: Sample NBD Configuration File [generic] listenaddr = 0.0.0.0 authfile = /etc/nbd-server/allow [diskfile] exportname = /dev/sdb1 copyonwrite = true port = 2000 [floppy] exportname = /dev/fd0 port = 2001 The easiest way to create a configuration file is to specify the
options you want and use the With configuration file created, you can pass it to Preparing an NBD Client With an NBD-enabled kernel running, you can use the # nbd-client nbdserver 2000 /dev/nbd0 In this example,
Although the basic
Using NBDs With your NBD client pointing to a network-accessible NBD server,
you can begin using NBD. You can treat your /dev/nbd#
device just as you would any local block device. Typically, you’ll
mount it as a filesystem (perhaps first creating a filesystem on it)
with # mount /dev/nbd0 /mnt/nbd This command mounts the device at /mnt/nbd. If the device
was exported for read/write operations, you’ll be able to write to it,
with the caveat that two clients should not connect to the same
read/write device simultaneously unless you use the Of course, you can also perform other operations on an NBD, such as
use When you’re done using an NBD that you’ve mounted, you can unmount
it using One of the problems with NBDs is that, if a network connection goes down or a server crashes, clients will have a hard time recovering. Data may be lost, much as in a local disk crash. To guard against such problems, I recommend using NBDs for brief periods, if possible; if you don’t need access to the NBD now, unmount it. Try to avoid using NBDs over anything but local networks. NBD traffic is unencrypted, so passing it over wireless networks or the Internet can be risky from a security point of view. Overall, NBDs can fill some specialized needs in a Linux network. If NFS or SMB/CIFS just doesn’t seem to fill your needs, give NBDs a try. -- Subscription settings: http://groups.google.com/group/linuxkernelnewbies/subscribe?hl=en |