ADMIN+Magazine+Sample+PDF

OCFS2
Tools
F Figure 2: Unspectacular:
the OCFS2 mount
process.
E Figure 3: Automatic
reboot after 20 seconds
on OCFS2 cluster
errors.
can modify the defaults to suit your
needs. The easiest approach here is
via the /etc/init.d/o2cb configure
script, which prompts you for the
required values – for example, when
the OCFS2 cluster should regard a
node or network connection as down.
At the same time, you can specify
when the cluster stack should try to
reconnect and when it should send a
keep-alive packet.
Apart from the heartbeat timeout,
all of these values are given in milliseconds.
However, for the heartbeat
timeout, you need a little bit of math
to determine when the cluster should
consider that a computer is down.
The value represents the number of
two-second iterations plus one for
the heartbeat. The default value of 31
is thus equivalent to 60 seconds. On
larger networks, you might need to
increase all these values to avoid false
alarms.
If OCFS2 stumbles across a critical
error, it switches the filesystem
to read-only mode and generates a
kernel oops or even a kernel panic.
In production use, you will probably
want to remedy this state without
in-depth error analysis (i.e., reboot
the cluster node). For this to happen,
you need to modify the underlying
operating system so that it automatically
reboots in case of a kernel oops
or panic (Figure 3). Your best bet for
this on Linux is the /proc filesystem
for temporary changes, or sysctl if
you want the change to survive a
reboot.
Just like any other filesystem, OCFS2
has a couple of internal limits you
need to take into account when designing
your storage. The number
of subdirectories in a directory is
restricted to 32,000. OCFS2 stores
data in clusters of between 4 and
1,024Kb. Because the number of
cluster addresses is restricted to 232,
the maximum file size is 4PB. This
limit is more or less irrelevant because
another restriction – the use
of JBD journaling – limits the maximum
OCFS2 filesystem size to 16TB,
which can address a maximum of 232
blocks of 4KB.
An active OCFS2 cluster uses a
handful of processes to handle
its work (Listing 5). DLM-related
tasks are handled by dlm_thread,
dlm_reco_thread, and dlm_wq. The
ocfs2dc, ocfs2cmt, ocfs2_wq, and
ocfs2rec processes are responsible
for access to the filesystem. o2net
and o2hb‐XXXXXXXXXX handle cluster
communications and the heartbeat.
All of these processes are started and
stopped by init scripts for the cluster
framework and OCFS2.
OCFS2 stores its management files
in the filesystem’s system directory,
which is invisible to normal commands
such as ls. The debugfs.ocfs2
command lets you make the system
directory visible (Figure 4). The
objects in the system directory are
divided into two groups: global and
Listing 4: Maintenance with tunefs.ocfs2
# tunefs.ocfs2 ‐Q "NumSlots = %N\n" /dev/sda1
NumSlots = 2
# tunefs.ocfs2 ‐N 4 /dev/sda1
# tunefs.ocfs2 ‐Q "NumSlots = %N\n" /dev/sda1
NumSlots = 4
#
# tunefs.ocfs2 ‐Q "Label = %V\n" /dev/sda1
Label = data
# tunefs.ocfs2 ‐L oldata /dev/sda1
# tunefs.ocfs2 ‐Q "Label = %V\n" /dev/sda1
Label = oldata
#
Listing 5: OCFS2 Processes
Figure 4: The metadata for OCSFS2 are stored in files that are invisible to the ls command. They can be listed
with the debugfs.ocfs2 command.
# ps ‐ef|egrep '[d]lm|[o]cf|[o]2'
root 3460 7 0 20:07 ? 00:00:00 [user_dlm]
root 3467 7 0 20:07 ? 00:00:00 [o2net]
root 3965 7 0 20:24 ? 00:00:00 [ocfs2_wq]
root 7921 7 0 22:40 ? 00:00:00
[o2hb‐BD5A574EC8]
root 7935 7 0 22:40 ? 00:00:00 [ocfs2dc]
root 7936 7 0 22:40 ? 00:00:00 [dlm_thread]
root 7937 7 0 22:40 ? 00:00:00 [dlm_reco_
thread]
root 7938 7 0 22:40 ? 00:00:00 [dlm_wq]
root 7940 7 0 22:40 ? 00:00:00 [ocfs2cmt]
#
www.admin-magazine.com
Admin 01
39