FreeBSD gstripe Operations: Build and Operate a Nonredundant GEOM Stripe

The GEOM stripe class combines two or more providers into one larger logical provider by distributing ranges across its members. This can increase usable aggregate capacity and allow concurrent I/O across devices, but gstripe does not mirror, parity-protect, or reconstruct data. If one member is lost, the filesystem built on the stripe is generally unavailable and its data may be lost. Treat gstripe as a performance and capacity layout whose failure domain includes every member.

This guide focuses on the operational decisions around gstripe(8), not a universal recipe for production storage. Every command that labels providers or creates a filesystem can write metadata and destroy existing data. Start with disposable devices or a verified backup and a documented change plan. Never paste example device names into a live shell without identifying each underlying disk.

Inventory providers and their ownership

First map candidate devices to physical or virtual storage identifiers. GEOM names such as da0 or ada1 are runtime paths, not durable asset identity. Record serial numbers, enclosure slots, controller ports, LUN identifiers, sector sizes, media sizes, and any existing GEOM consumers.

geom disk list
geom part list
camcontrol devlist
gpart show
gstripe status

Inspect the full output before any write. A provider may be a partition, a whole disk, an encrypted GEOM device, a mirror, a virtual disk, or a path to shared storage. Select a consistent layer for all members. Do not mix a whole device and one of its partitions, or consume a provider already used by a mounted filesystem, swap, ZFS, or another GEOM class.

Confirm that the members have compatible media and sector sizes. gstripe can create a larger provider whose size is constrained by the smallest member; the exact reported usable size also accounts for metadata in automatic mode. Unequal sizes can leave capacity unused, while mismatched sector geometry can produce alignment problems. Review the actual values rather than assuming nominal drive capacities are identical.

Take a read-only baseline of filesystems, mounts, and labels:

mount
swapinfo
gpart show -lp
geom label list

If a provider is busy or ownership is unclear, stop. Do not force a destructive operation or attempt to “fix” the problem by destroying a GEOM class. Resolve consumers using the appropriate service or filesystem procedure. A gstripe rollout should not begin by guessing which provider is safe to erase.

Choose metadata-backed labeling or manual creation

gstripe supports automatic and manual configuration. The label method writes metadata to members so the array can be detected again after a restart. The create method stores no on-disk metadata; the administrator must reconstruct the array manually whenever required. For most persistent data layouts, metadata-backed configuration is easier to recover consistently, but it is not a substitute for backups or an inventory.

An example using four deliberately empty test providers and a 128 KiB stripe interleave is:

gstripe label -v -s 131072 archive /dev/da0 /dev/da1 /dev/da2 /dev/da3
gstripe status
geom disk list

The sample is destructive to the extent that it writes GEOM metadata on the chosen providers. It must not be run on production devices merely because those device names appear in a guide. The -s value is measured in bytes for gstripe, unlike the sector-count convention used by ccdconfig. A stripe size that works for one database, backup job, or filesystem may be poor for another.

The metadata-backed provider is normally exposed under /dev/stripe/name. Check the actual nodes and gstripe status before continuing. Do not assume that a successful label command means that the operating system selected the intended physical disks; verify the metadata and mapping using the output and the current inventory.

Manual mode has a different lifecycle:

gstripe create -s 131072 archive /dev/da0 /dev/da1
gstripe status

Because manual mode writes no metadata, it is not automatically rediscovered in the same way as a label-backed array. Your boot configuration and runbook must recreate the exact provider set before mounting or using the filesystem. This can be useful for temporary test arrangements, but undocumented manual reconstruction is operationally fragile. Do not use a manual example as a persistence mechanism unless the boot sequence has been tested.

Think about stripe size and workload shape

The interleave controls how consecutive logical ranges are assigned across members. A smaller stripe can spread small sequential requests across more devices, but may increase the number of members involved in a request. A larger stripe can keep medium or large sequential transfers on a member for longer, which may be useful for certain streaming workloads, but it can reduce parallelism for small random requests. The best value depends on request size, queue behavior, number and type of devices, filesystem layout, controller, and application concurrency.

Do not choose a stripe size from a generic “best practice” table alone. Establish a baseline using representative reads and writes, then test on non-production data with the same filesystem settings and device stack. Separate warm-cache results from device-bound tests, use repeatable block sizes and queue depths, and track tail latency as well as throughput. Avoid comparing one run with a full system and another with idle disks.

GEOM I/O counters and device statistics help identify whether all members receive work, but they do not prove the application benefits. Check application response time and failure behavior. If the workload is dominated by latency-sensitive small writes, a stripe may be worse than a single suitable device. If the goal is protection from drive loss, choose a redundant design such as a mirror or RAID-Z rather than trying to tune a stripe into a redundancy mechanism.

Create a filesystem only after the array is proven

Before formatting, confirm that the provider name is exactly the intended array and that all source devices are dedicated and backed up. A filesystem creation command overwrites existing structures:

gstripe status
geom disk list
newfs /dev/stripe/archive

Run newfs only on a new, verified provider. Never run it as a diagnostic step. After filesystem creation, mount it at a controlled temporary path and validate capacity, ownership, write/read behavior, and reboot persistence before adding it to production configuration. Retain the exact provider identity and filesystem UUID or label according to the actual filesystem tooling used.

Do not mount the underlying members individually after the stripe has been created. The filesystem belongs on the logical array provider. Using a member path directly can corrupt the structure or bypass the expected mapping. Keep the original member inventory in the operations record even if normal use references only /dev/stripe/archive.

Boot, monitor, and recover deliberately

For automatic labels, verify that the GEOM class is available early enough for the intended boot and mount order. If the module is not built into the kernel, the gstripe manual documents geom_stripe_load=“YES” in loader.conf. Confirm the actual kernel module name and boot-time behavior on the installed FreeBSD release before persisting it. A successful runtime test does not establish that the array will appear during boot.

Check status after boot and after any controller, disk, or firmware maintenance:

gstripe list
gstripe status
gstripe dump /dev/da0
dmesg | tail -100

The dump operation is a metadata inspection tool; target it only at the provider whose metadata you intend to examine. Confirm that the expected members and stripe configuration are present. Monitor each component device and the GEOM layer rather than relying on a single aggregate filesystem free-space number.

There is no parity reconstruction or mirror resynchronization path for ordinary gstripe. A failed member is an outage affecting the logical volume. Restore the filesystem and data from backup onto a replacement design, or follow a vendor/storage-system recovery process if the members are virtualized. Do not remove a failed component and expect the surviving members to present a complete filesystem. Repeatedly attaching mismatched disks or trying to “degrade” the stripe risks making recovery harder.

If an array is being retired, first unmount all consumers, stop applications, disable swap if applicable, remove persistent mount or startup configuration, and verify that the provider is no longer open. Then use the documented stop or destroy operations only after the data has been migrated and validated. Clearing metadata is not equivalent to securely erasing data.

Operational acceptance criteria

Before putting a gstripe volume into service, document the purpose, member identifiers, provider layer, metadata method, stripe-size rationale, filesystem settings, boot dependencies, baseline measurements, restore evidence, and an explicit statement that it has no redundancy. Recheck the array after reboot, validate representative I/O and application behavior, and test restoration from backup on a separate destination.

Define alerting for a missing provider, unexpected device errors, degraded underlying hardware, and capacity thresholds. gstripe status itself is not a complete health signal for every device path. Pair it with device logs, controller telemetry, filesystem checks appropriate to the filesystem, and backup monitoring. Do not suppress warnings because the array still mounts.

For a single-host scratch volume whose data can be recreated, the capacity/performance tradeoff may be acceptable. For user data, databases, or backups, compare the cost of a nonredundant failure domain with a mirrored or parity-protected design. More disks in a stripe may improve parallelism, but they also add members whose loss can make the entire logical volume unusable. That is the central design constraint, not an incidental caveat.

Related:

Sources: