ADMIN

Tools
OCFS2
local (i.e., node-specific) files. The
first of these groups includes global_
inode_alloc, slot_map, heartbeat,
and global_bitmap. They have access
to each node on the cluster; inconsistencies
are prevented by a locking
mechanism. The only programs that
access global_inode_alloc are those
for creating and tuning the filesystem.
To increase the number of slots, it
Listing 6: Debugging with mounted.ocfs2
# grep ‐i ocfs /proc/mounts |grep ‐v dlm
# hostname
testvm2.seidelnet.de
# tunefs.ocfs2 ‐L olddata /dev/sda1
tunefs.ocfs2: Trylock failed while opening device "/dev/
sda1"
# mounted.ocfs2 ‐f
Device FS Nodes
/dev/sda1 ocfs2 testvm
#
Listing 7: Restoring Corrupted OCFS2 Superblocks
# mount /dev/sda1 /cluster/
mount: you must specify the filesystem type
# fsck.ocfs2 /dev/sda1
fsck.ocfs2: Bad magic number in superblock while opening
"/dev/sda1"
# fsck.ocfs2 ‐r1 /dev/sda1
[RECOVER_BACKUP_SUPERBLOCK] Recover superblock
information from backup block#262144? y
Checking OCFS2 filesystem in /dev/sda1:
label:
backup
uuid:
31 18 de 29 69 f3 4d 95 a0 99 a7
23 ab 27 f5 04
number of blocks: 367486
bytes per block: 4096
number of clusters: 367486
bytes per cluster: 4096
max slots: 2
/dev/sda1 is clean. It will be checked after 20
additional mounts.
#
Listing 8: Enabling/​Disabling OCFS2 v1.4 Features
# tunefs.ocfs2 ‐Q "Incompatible: %H\n" /dev/sda1
Incompatibel: sparse inline‐data
# tunefs.ocfs2 ‐‐fs‐features=nosparse /dev/sda1
# tunefs.ocfs2 ‐Q "Incompatible: %H\n" /dev/sda1
Incompatibel: inline‐data
# tunefs.ocfs2 ‐‐fs‐features=noinline‐data /dev/sda1
# tunefs.ocfs2 ‐Q "Incompatible: %H\n" /dev/sda1
Incompatibel: None
#
# tunefs.ocfs2 ‐‐fs‐features=sparse,inline‐data /dev/
sda1
# tunefs.ocfs2 ‐Q "Incompatible: %H\n" /dev/sda1
Incompatibel: sparse inline‐data
#
is necessary to create further nodespecific
system files.
What Else?
When you make plans to install
OCFS2, you need to know which version
you will putting on the new machine.
Although the filesystem itself –
that is, the structure on the medium
– is downward compatible, mixed operations
with OCFS2 v1.2 and OCFS2
v1.4 are not supported. The network
protocol is to blame for this. The developers
enabled a tag in the active
protocol version so that future OCFS2
versions would be downward compatible
through the network stack. This
comes at the price of incompatibility
with v1.2. Otherwise, administrators
have a certain degree of flexibility
when mounting OCFS2 media. OCFS2
v1.4 computers will understand the
data structure of v1.2 and mount
them without any trouble. This even
works the other way around: If the
OCFS2 v1.4 volume does not use the
newer features in this version, you
can use an OCFS2 v1.2 computer to
access the data.
Debugging
A filesystem has a number of potential
issues, and the added degree of
Feature
Table 3: New Features in OCFS2 v1.4
Ordered journal mode
Flexible allocation
Inline data
Clustered flock()
OCFS2 Choices
Description
Administrators will basically come across two
versions of OCFS2: version 1.2 or 1.4. As regards
the data structure on disk, the two versions
are compatible; however, this does mean
doing without the newer features in v1.4. The
documentation lists 10 significant differences
between versions 1.2 and 1.4. Table 3 lists the
most interesting of these. No matter which
version you decide on, you should always
watch for a couple of things.
complexity in a cluster filesystem
doesn’t help. From the viewpoint of
OCFS2, things can go wrong in three
different layers – the filesystem structure
on the disk, the cluster configuration,
or the cluster infrastructure –
or even a combination of the three.
The cluster infrastructure includes
the network stack for the heartbeat,
cluster communications, and possibly
media access. Problems with Fibre
Channel (FC) and iSCSI also belong
to this group.
For problems with the cluster infrastructure,
you can troubleshoot just
as you would for a normal network,
FC, or iSCSI problems. Problems can
also occur if the cluster configuration
is not identical on all nodes. Armed
with vi, scp, and md5sum, you can
check this and resolve the problem.
The alternative – assuming the cluster
infrastructure is up and running – is
to synchronize the cluster configuration
on all of your computers by
updating the configuration with ocfs‐
2console.
It can be useful to take the problematic
OCFS2 volume offline – that is,
to unmount it and restart the cluster
service on all of your computers by
giving the /etc/init.d/o2cb restart
command. You can even switch the
filesystem to a kind of single-user
mode with tunefs.ocfs2.
OCFS2 writes data before metadata.
OCFS2 now supports sparse files – that is, gaps in files. Additionally,
preallocation of extents is possible.
OCFS2 stores the data from small files directly in the inode and not in
extents.
The flock() system call is cluster capable.
The mkfs.ocfs2 supplied with version 1.4
automatically enables all the new features,
thus effectively preventing OCFS v1.2 machines
from accessing the filesystem. To
change this, use tunefs.ocfs2 to disable
the new functions (Listing 8). An easier approach
is to create the filesystem with the
‐‐fs‐feature‐level=max‐compat
option set. tunefs.ocfs2 will help you migrate
from version 1.2 to 1.4.
40 Admin 01 www.admin-magazine.com