Welcome to the Linux Foundation Forum!

Memory-mapped files on am EBS volume

denis2025
denis2025 Posts: 1
in Kernel Development

First time posting here -- apologies if this question is not appropriate for this forum.

My code is using a library that reads from and writes to a mmap'd file. Right now the file resides on an SSD, and there has been a conversation about hosting it on an EBS volume instead. What would be the risks of doing that? Specifically:

  • What would happen when the library attempts to read a page that's not in physical memory while the EBS volume is temporarily unavailable due to network issues?
  • What would happen when the OS attempts to flush a dirty page to the EBS volume while it's temporarily unavailable due to network issues?

Thanks in advance!

Answers

  • nick.accuweb.cloud
    nick.accuweb.cloud Posts: 2

    @denis2025,

    Please find the risk factors when you move the files from SSD to the EBS volume. Let’s unpack the 3 cases:

    1. Reading a page from EBS when it’s unavailable

    When your program uses a memory-mapped file and tries to read data that isn’t already in memory, the operating system (OS) loads that data from storage.

    If the storage is on EBS (Amazon’s network-based disk), this means the OS must fetch the data over the network.

    If there’s a temporary network or EBS issue:

    The read will pause and your program will hang until the OS gets a response.

    If the problem is short-lived, it may recover and continue normally.

    If the problem is serious (EBS disconnects, network breaks, etc.), the OS will return an error.

    When that happens, your program may get a “bus error” (SIGBUS), which often causes a crash unless it’s handled in code.

    In short: reading from an EBS-backed mmap file can freeze or crash your program if the EBS volume goes offline.

    1. Flushing dirty pages to an unavailable EBS volume

    When the OS needs to save modified data (dirty pages) from memory back to the EBS disk:

    It starts a write operation to EBS.

    If EBS is slow or has temporary issues, the write will stall while the OS keeps retrying.

    If the problem lasts, the OS will return I/O errors.

    Depending on the filesystem:

    The filesystem may switch to read-only mode to protect data.

    Your program may see errors when calling msync() or fsync().

    Later writes to the mapped file could again trigger a SIGBUS error.

    In short: failed writes can freeze your app, cause crashes, or make the filesystem unstable — though journaling filesystems (like ext4) usually prevent total corruption.

    1. Practical implications

    Using memory-mapped files on EBS comes with these risks:

    Reads or writes can freeze due to network delays or retries.

    Your program can crash (SIGBUS) if EBS disconnects.

    The filesystem can become read-only or throw errors if EBS stays unavailable.

    By comparison, a local SSD is faster and only fails if the hardware breaks — which is rarer and simpler to handle.

    Regards,
    Nick R
    Cloud Team Lead
    AccuWeb.Cloud

Categories

Upcoming Training