How to Enable File Cached Memory in Ubuntu Server for Faster Access

Ubuntu Server does not have a single toggle to "enable file cached memory" because Linux already uses the kernel page cache aggressively. To improve media playback speeds, you must optimize I/O scheduling, disable unnecessary write-back delays, and ensure your storage controller is configured for low latency rather than high throughput.

Understanding Linux Page Cache

The concept of "file caching" in Ubuntu is handled automatically by the kernel’s Virtual Memory Subsystem. When you access a file, the kernel reads data from disk into RAM (the page cache). Subsequent reads are served directly from RAM unless the cache is evicted due to memory pressure. There is no specific service or daemon called "File Cached Memory" that you need to start. Misunderstanding this often leads users to search for non-existent settings or install third-party tools that offer little benefit over native kernel behavior. For media servers like Plex or Jellyfin, the bottleneck is rarely the lack of caching; it is usually the speed at which data can be read from the disk into the cache and then streamed to the client. Therefore, optimization focuses on ensuring the disk subsystem keeps up with the stream.

Checking Current Cache Usage

You can verify how much memory is being used for caching by checking the /proc/meminfo file. Look for the line labeled Cached. This value represents the total amount of memory used to cache filesystem data. If this number is consistently near zero during heavy media access, your system might be under severe memory pressure, or the application is bypassing the cache using direct I/O. To see real-time cache activity, use the iostat command from the sysstat package:

sudo apt install sysstat
iostat -x 1

Look at the await column. High values here indicate that processes are waiting for I/O operations to complete, suggesting the disk is the bottleneck, not the cache.

Optimizing I/O Scheduling

The I/O scheduler determines how requests are ordered and merged before being sent to the storage device. The default scheduler varies by kernel version and storage type. For solid-state drives (SSDs) and NVMe drives, the none or mq-deadline schedulers are generally preferred because they reduce overhead. For traditional spinning hard drives (HDDs), bfq (Budget Fair Queuing) or deadline can help prioritize time-sensitive reads, such as those required for smooth video playback. To check your current scheduler, run:

cat /sys/block/sda/queue/scheduler

Replace sda with your actual block device name. You can change the scheduler temporarily for testing:

echo mq-deadline > /sys/block/sda/queue/scheduler

To make this persistent across reboots, create a systemd-udev rule. Create a file named /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="mq-deadline"

This approach ensures that your storage device uses an efficient queuing strategy, reducing latency during concurrent media requests.

Tuning VM Dirty Ratio

Linux buffers writes in memory before flushing them to disk to improve performance. However, if the buffer becomes too large, it can cause latency spikes when the system finally flushes the data. For a media server where read performance is critical, you can tune the dirty ratio settings to minimize these spikes. Edit /etc/sysctl.conf and add the following lines:

# Reduce the percentage of memory that can hold dirty pages
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

# Flush dirty pages more frequently
vm.dirty_expire_centisecs = 1000
vm.dirty_writeback_centisecs = 500

Apply these changes with:

sudo sysctl -p

These settings ensure that dirty data is flushed to disk more frequently and in smaller batches, preventing sudden I/O storms that could interrupt media streaming.

Disabling Write-Back Delays

Some filesystems, particularly ext4, have mount options that affect how metadata and data are written. By default, ext4 uses data=ordered, which ensures file consistency but adds some overhead. For media servers where data integrity is less critical than speed, you might consider data=writeback, though this carries a risk of corruption if the system crashes unexpectedly. A safer alternative is to adjust the commit interval. Add commit=60 to your /etc/fstab entry for the media drive:

/dev/sdb1 /media/media ext4 defaults,commit=60 0 2

Then remount the filesystem:

sudo mount -o remount /media/media

This reduces the frequency of forced commits, allowing the kernel to batch writes more efficiently.

Hardware and Network Considerations

Often, perceived slow caching is actually network latency or hardware limitations. Ensure your network interface is negotiating at full speed. Check with ethtool eth0 to confirm link speed. Additionally, if you are using SMB/CIFS shares, enable multi-channel support if available, as it allows multiple connections to aggregate bandwidth. If your media library is huge, consider using a dedicated SSD for the most frequently accessed titles while keeping the rest on slower HDDs. This hybrid approach leverages the fast cache effectively without requiring massive amounts of RAM.

Frequently Asked Questions

Does enabling ZRAM improve media playback?

ZRAM compresses data in RAM, which can help if you are severely memory-constrained. However, compression requires CPU cycles, which may introduce latency during playback. It is generally better to increase physical RAM or optimize I/O scheduling rather than relying on ZRAM for media serving.

How do I know if my disk is the bottleneck?

Use iostat -x and monitor the %util and await columns. If %util is near 100% and await is high, your disk cannot keep up with the read requests. In this case, upgrading to an SSD or RAID configuration will provide more significant gains than software tweaks.

Is it safe to change the I/O scheduler?

Yes, changing the I/O scheduler is safe and reversible. However, the optimal scheduler depends on your specific hardware. Testing different schedulers with your actual workload is the best way to determine which provides the lowest latency for your setup.

Why is my media stuttering despite having plenty of RAM?

Stuttering is often caused by network congestion or inefficient filesystem mounts. Check your network throughput and ensure your SMB/NFS settings are optimized. Also, verify that the media files are not fragmented, as fragmentation can cause seek delays even with ample cache.

Can I disable the page cache entirely?

No, disabling the page cache would severely degrade performance because every read would require a direct disk access. The goal is to maximize cache efficiency, not remove it. Applications can request direct I/O via specific flags, but this is rare and usually detrimental for general media playback.