---
title: "💭 Performance Difference between RWX and RWO volumes · longhorn/..."
description: "!https://github.com/longhorn/longhorn/discussions/6964"
date: 2025-08-15
published: true
tags:
  - kubernets
  - longhorn
  - thought
template: link
---


<div class="embed-card embed-card-external">
  <a href="https://github.com/longhorn/longhorn/discussions/6964" class="embed-card-link" target="_blank" rel="noopener noreferrer">
    <div class="embed-card-image">
      <img src="https://opengraph.githubassets.com/3ef5e06da915e8435ecd50368f3eeb8e8f0e4ab29fb9f9a8617cf4465c9496bc/longhorn/longhorn/discussions/6964" alt="Performance Difference between RWX and RWO volumes · longhorn longhorn · Discussion #6964 — Hey all, because of some internal testing I made a couple of experiments on our Cluster related to performance of RWX and RWO volumes. Because this might be of interest to some people I thought I s..." loading="lazy">
    </div>
    <div class="embed-card-content">
      <div class="embed-card-title">Performance Difference between RWX and RWO volumes · longhorn longhorn · Discussion #6964</div>
      <div class="embed-card-description">Hey all, because of some internal testing I made a couple of experiments on our Cluster related to performance of RWX and RWO volumes. Because this might be of interest to some people I thought I s...</div>
      <div class="embed-card-meta">GitHub &middot; github.com</div>
    </div>
  </a>
</div>


Interesting longhorn storage performance test, author does highlight right away that this is a simulation and not a REAL test.  I did not fully understand the storage semantics before reading through this.

* **RWO** -  Always presents a filesystem `ext4` or `xfs`
* **RWX**/**ROX** - Always presents a network share `nfs` to the pod.

This is an important distinction for applications that use sqlite or a tool on top of sqlite such as diskcache.  With sqlite it is not recomended to run over nfs due to missing required file locking mechanisms.  

Longhorn storage still provides a lot of benefits to these applications as the storage is automatically replicated, if the node that your application is running on goes offline a new pod will start on an existing node.  If you have planned downtime, you can cordon and drain a node.  Since the data is available in another location you will be able to start a new pod on anther node.  barring your PodDisruptionBudget settings, taints, and affinity, this may happen automatically.

!!! note

    This post is a <a href="/thoughts/" class="wikilink" data-title="Thoughts" data-description="These are generally my thoughts on a web page or some sort of url, except a rare few don&#39;t have a link. These are dual published off of my..." data-date="2024-04-01">thought</a>. It's a short note that I make
    about someone else's content online <a href="/tags/thoughts/" class="hashtag-tag" data-tag="thoughts" data-count=2 data-reading-time=3 data-reading-time-text="3 minutes">#thoughts</a>