Skip to main content
Version: 4.5.x

Raw Block Volumes

Local PV Rawfile supports raw block volumes that expose a loop device directly to the pod without any filesystem layer. This is useful for databases and other workloads that manage their own storage format.

Create a Block Mode PVC​

Set volumeMode: Block in the PVC spec:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rawfile-block-pvc
spec:
  storageClassName: rawfile-localpv
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 10Gi
kubectl apply -f block-pvc.yaml

The PVC will remain in Pending state until a consuming pod is scheduled (WaitForFirstConsumer).

Consume the Block Volume in a Pod​

Use volumeDevices (not volumeMounts) to map the raw device into the pod:

apiVersion: v1
kind: Pod
metadata:
  name: app-block
spec:
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "sleep infinity"]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: rawfile-block-pvc
kubectl apply -f pod-block.yaml
kubectl get pvc rawfile-block-pvc

Once the pod is scheduled, the loop device is attached and exposed at /dev/xvda inside the container. The application is responsible for initializing and managing the device.

Verify the Block Device​

kubectl exec app-block -- ls -l /dev/xvda
# brw-rw---- 1 root disk 7, 3 ... /dev/xvda

kubectl exec app-block -- blockdev --getsize64 /dev/xvda
# 10737418240

StorageClass Parameters for Block Mode​

The following StorageClass parameters are ignored for block mode PVCs:

  • csi.storage.k8s.io/fstype - no filesystem is created
  • formatOptions - no format step
  • mountOptions - no mount step
  • copyOnWrite / freezeFs - CoW and freeze apply to filesystem operations only

All other parameters (storagePool, thinProvision, allowVolumeExpansion) continue to apply.

note

The readOnly attribute on block mode PVCs is not currently honored.

Volume Expansion​

Block mode volumes support online expansion. If the volume is currently unstaged (no pod using it), only the backing file is grown; node-side expansion is deferred until the volume is next attached. The application inside the pod is responsible for recognizing the larger device (e.g. re-reading partition tables, resizing the filesystem it manages).

Use Cases​

Use CaseWhy Block Mode
Databases (PostgreSQL, MySQL)Direct I/O without filesystem overhead
VM disk imagesRaw block device maps naturally to a virtual disk
Custom storage formatsApplication manages its own layout on the device

Support​

If you encounter issues or have a question, file a Github issue, or talk to us on the #openebs channel on the Kubernetes Slack server.

See Also​