Enterprise Storage Administration: Mounting SAN LUNs on Database Servers

When administering enterprise database clusters, decoupling your computing nodes from your storage subsystem is critical for performance and reliability. High-throughput transactional databases require dedicated storage LUNs (Logical Unit Numbers) provisioned from enterprise SAN (Storage Area Network) arrays like EMC Clariion or Symmetrix.

In this guide, I will walk you through the complete sysadmin workflow for provisioning new SAN LUNs to an enterprise database server: scanning SCSI buses, identifying target WWNs, formatting raw slices with the UFS filesystem, and establishing persistent mounts optimized for database direct I/O (forcedirectio).

Prerequisites

You will need an enterprise database server running Solaris/Linux with root privileges, alongside pre-zoned LUNs presented from your SAN storage administrators.

---

Step 1: Scanning SCSI Buses and Discovering LUNs

Once the storage team zones new LUNs to your server's Fibre Channel HBAs (Host Bus Adapters), you must scan the operating system SCSI bus to discover the new block devices.

# Scan SCSI bus to discover new SAN LUNs
cfgadm -al

# Verify multipathing status and identify newly presented DGC RAID 10 LUNs
echo "inquiry" | format

Identifying Target Controller and Slice Mappings

Executing format reveals the exact multipathed controller mappings (c4t... and c5t...) assigned by the virtual host controller interface (/scsi_vhci/):

17. c4t600601600890290066A9055B8C90E211d0 <DGC-RAID10-0532 cyl 57342 alt 2 hd 128 sec 10>  p1
    /scsi_vhci/ssd@g600601600890290066a9055b8c90e211
18. c4t600601600890290067A9055B8C90E211d0 <DGC-RAID10-0532 cyl 57342 alt 2 hd 128 sec 10>  p3
    /scsi_vhci/ssd@g600601600890290067a9055b8c90e211
19. c4t6006016008902900B6D688738C90E211d0 <DGC-RAID10-0532 cyl 57342 alt 2 hd 128 sec 10>  l0
    /scsi_vhci/ssd@g6006016008902900b6d688738c90e211
20. c4t6006016008902900B7D688738C90E211d0 <DGC-RAID10-0532 cyl 57342 alt 2 hd 128 sec 10>  l3
    /scsi_vhci/ssd@g6006016008902900b7d688738c90e211

---

Step 2: Initializing and Formatting Raw Slices (newfs)

Before mounting the newly discovered LUNs, initialize the raw disk slices (s2 representing the entire disk slice in Solaris) with the UFS filesystem.

Execute newfs across the raw disk character devices (/dev/rdsk/):

# Format transaction log and data LUNs with UFS
newfs /dev/rdsk/c5t6006016008902900B8BE62F98890E211d0s2
newfs /dev/rdsk/c5t6006016008902900B9BE62F98890E211d0s2
newfs /dev/rdsk/c5t6006016008902900BA646E9F8990E211d0s2
newfs /dev/rdsk/c5t6006016008902900BB646E9F8990E211d0s2
newfs /dev/rdsk/c5t6006016008902900ECA76E5B8890E211d0s2
newfs /dev/rdsk/c5t6006016008902900EDA76E5B8890E211d0s2

---

Step 3: Creating Mount Points and Enforcing Permissions

Create dedicated directory mount points for your database datafiles (/p1, /p3), transaction logs (/l0, /l3), and temporary table spaces (/t1, /t3).

# Create mount directories
mkdir /t1 && mkdir /t3 && mkdir /p1 && mkdir /p3 && mkdir /l0 && mkdir /l3

# Assign strict ownership to database service user (informix)
chown -R informix:informix /t1 && chown -R informix:informix /t3
chown -R informix:informix /p1 && chown -R informix:informix /p3
chown -R informix:informix /l0 && chown -R informix:informix /l3

---

Step 4: Establishing Persistent Mounts (/etc/vfstab)

To ensure the LUNs mount automatically on system boot and are optimized for database performance, add persistent entries to /etc/vfstab.

Understanding Database Mounting Flags (forcedirectio)

When mounting database datafiles on UFS, adding forcedirectio forces the operating system to bypass the kernel buffer cache and perform I/O directly to the disk. This eliminates CPU overhead and prevents double-buffering, dramatically increasing database transactional throughput.

# /etc/vfstab
# Device                                              Device to fsck                                       Mount Point   FS Type  Pass  At Boot  Mount Options
/dev/dsk/c4t6006016070031B00E04E1EBC8190E211d0s2      /dev/rdsk/c4t6006016070031B00E04E1EBC8190E211d0s2      /t1           ufs      2     yes      -
/dev/dsk/c4t6006016070031B00E14E1EBC8190E211d0s2      /dev/rdsk/c4t6006016070031B00E14E1EBC8190E211d0s2      /t3           ufs      2     yes      -
/dev/dsk/c4t6006016070031B00445A468D8290E211d0s2      /dev/rdsk/c4t6006016070031B00445A468D8290E211d0s2      /l0           ufs      2     yes      forcedirectio
/dev/dsk/c4t6006016070031B00455A468D8290E211d0s2      /dev/rdsk/c4t6006016070031B00455A468D8290E211d0s2      /l3           ufs      2     yes      forcedirectio
/dev/dsk/c4t6006016070031B00781EF22A8290E211d0s2      /dev/rdsk/c4t6006016070031B00781EF22A8290E211d0s2      /p1           ufs      2     yes      forcedirectio
/dev/dsk/c4t6006016070031B00791EF22A8290E211d0s2      /dev/rdsk/c4t6006016070031B00791EF22A8290E211d0s2      /p3           ufs      2     yes      forcedirectio

Mount all filesystems in /etc/vfstab and verify active allocations:

mountall
df -h

References

• Oracle Solaris Administration: ZFS and UFS Filesystems