I finally gave up on trying to make SSDs play well with Unraid. Parity is building on a new HDD array I'm building right now.

 

My main interest in trying to get SSDs to work was this: avoiding mechanical head contention on hard drives if two different files are being read from the same drive at once. Going back to using HDDs means that this is once again a potential concern.

 

My array is for serving video. That makes smooth data streaming without any significant delays a must.

 

I realize HDDs typically have their own built-in cache. The drives I'm using each have 256MB of cache. But as far as I know, this caching is based on access frequency, not anticipated read-ahead, so that caching is likely no help in avoiding video playback hiccups.

 

At the file system level, within the Unraid OS, can I set something up so that when a file is opened (perhaps only specific files, like *.mkv files) extra data beyond that which is specifically requested is read in and cached? 256MBs-worth would be great, worth about two-minutes of playback for a fairly typical HD movie.

Edited March 17, 20251 yr by RasterEyes

is it possible to make one yes... getting unraid to use it is another story... Theses are advance linux and can break / brick stuff You have been warnned...

Look into ram disk / zdisk... Mainfrezer has some plugin in CA to use a ram disk for dockers as example and there are some scripts lost on the forum...

 

BUT Yes, you can set up a RAM-based read-ahead cache in unRAID to improve video playback smoothness. Since you're streaming media from HDDs and concerned about mechanical head contention, a RAM cache will help reduce disk seeks and keep playback smoother.

Here are a few options you can try:

 

1. Increase Linux Read-Ahead Buffer (Preferred)

Linux has built-in disk read-ahead buffering, which unRAID inherits. You can increase it for your HDDs manually:

How to Set Up Read-Ahead Cache

 

Check the current read-ahead value Open a terminal in unRAID and run:

blockdev --getra /dev/sdX

(Replace /dev/sdX with the actual device name of your media drives.)

 

Increase the read-ahead buffer

blockdev --setra 2048 /dev/sdX

This increases read-ahead to 1MB (each unit = 512 bytes), meaning that the drive will pre-fetch 1MB beyond each read request. You can try 4096 (2MB) or 8192 (4MB) for even more aggressive caching.

 

Make it Persistent Add this to your /boot/config/go file to reapply on reboot:

(I'm more a fan of user script plugin and at array start)
 

# Set read-ahead on media drives
for drive in /dev/sdX /dev/sdY; do
    blockdev --setra 4096 $drive
done

 

 

2. ZRAM or ZSWAP for Compressed Caching (Experimental) --more a zfs pool only setup thing...

If you want a RAM-based cache, you can use zram to create a compressed block cache.

 

modprobe zram
echo 1 > /sys/block/zram0/reset
echo $((512*1024*1024)) > /sys/block/zram0/disksize  # 512MB cache
mkswap /dev/zram0
swapon /dev/zram0 -p 100

 

Make It Persistent

Add the above lines to /boot/config/go so it runs on startup.

Increase disksize to 1GB+ if needed.

...

 

 

 

 

3. Use a RAMDisk (If You Have Enough RAM)

If you have plenty of RAM (32GB+), you could mount a small tmpfs (RAM disk) and cache frequently used media there:

 

Create a RAM Disk

mkdir /mnt/ramdisk
mount -t tmpfs -o size=4G tmpfs /mnt/ramdisk

 

Copy Movies to RAM Before Playback

cp /mnt/user/media/movies/movie.mkv /mnt/ramdisk/

This avoids any disk access, keeping playback ultra-smooth.

 

#########

Best quick fix? Increase Linux read-ahead (blockdev --setra).

Want something more aggressive? Try zram caching.

Have a ton of RAM? Use a RAM disk for temporary media caching.

 

 

 

Edited March 18, 20251 yr by bmartino1
Data

1 hour ago, bmartino1 said:

 

blockdev --setra 4096 $drive

 

Thank you! Very helpful.

Would it be safe to go as high as 131072, 64MB, for roughly 30 seconds worth of HD video content? I've got "only" 16GB of RAM, but nothing else going on with the array other than being a simple file server, no Docker apps or the like.

Edited March 18, 20251 yr by RasterEyes

this sets the setting to that disk it will be set and used at that time. Dpends on the disk and the abilty to cache, read write.
also depends on the disk file system and other system resources...


Sadly this is test and experiment areas. your milage will vary. is it safe to do so, kinda. but yes.

 

The blockdev --setra command sets the readahead buffer size in 512-byte sectors. So, when you set:

 

4096, it means 2MB of readahead (4096 × 512B).

 

131072, it means 64MB of readahead (131072 × 512B).

 

Considerations for Increasing to 64MB (131072):

 

-RAM Usage:

With 16GB of RAM and minimal other loads, 64MB per disk isn't a problem unless you have a large number of drives.

If your system runs into memory pressure, excessive readahead could cause unnecessary swapping.

 

-Performance Impact:

Large readahead values help sequential reads, such as video streaming.

However, if your usage includes random access, too much readahead could hurt performance (e.g., unnecessary reads).

File servers often benefit from moderate readahead, but 64MB may be overkill unless your access patterns involve very large, continuous reads.

 

Practical Testing:

You can experiment dynamically without a reboot

blockdev --setra 131072 /dev/sdX  # Test on a single drive

 

Then check if performance improves using

hdparm -tT /dev/sdX

--If things slow down (or cause excessive memory usage), dial it back.

 

Suggested Approach:

Start at 8MB or 16MB (16384 or 32768 sectors) and incrementally test.

If no performance issues arise, then try 64MB (131072).

Monitor RAM usage using htop or free -h.

yes it is safe.

Review:

 

https://serverfault.com/questions/148016/linux-read-ahead-downsides

 

https://www.ibm.com/docs/en/cloud-paks/cp-management/2.3.x?topic=storage-setting-readahead-drive-volume-local

 

https://www.kernel.org/doc/ols/2007/ols2007v2-pages-273-284.pdf

 

27 minutes ago, bmartino1 said:

yes it is safe.

 

Thanks. I won't be able to experiment much immediately, as I've got a day or two until all of my movie content is restored to the new array I just finished building.

It's too bad I can't restrict this kind of read-ahead caching by file extension to just *.mkv files.

12 minutes ago, RasterEyes said:

Thanks. I won't be able to experiment much immediately, as I've got a day or two until all of my movie content is restored to the new array I just finished building.

It's too bad I can't restrict this kind of read-ahead caching by file extension to just *.mkv files.

 

Agreed... kinda (will get into the weeds a bit)... depends on how the file is being accessed to play... There are some application that will transcode and servers like dlna and smaba that have options to do some buffering and readahead based on file types... Just another thing to throw towards the feature request to add a custom share options to unraid samba config....

Unfortunately, blockdev --setra applies globally to an entire block device and does not provide a way to restrict read-ahead caching to specific file types (like *.mkv). However, you can achieve a similar effect using other methods:

 

A Solution: Using vfs_read_ahead in Samba (for network shares)

If you're serving video files over a network (Samba/SMB), you can optimize read-ahead only for .mkv files using Samba’s vfs_read_ahead module.

 

Enable vfs_read_ahead for Video Files example per share... (Unriad has moved these file and edited them its posble to write your own smb conf...
Edit your Samba configuration (/etc/samba/smb.conf) and add:
 

[media]
path = /path/to/media
vfs objects = read_ahead
read_ahead:readahead = 65536

This enables 64MB (65536 KB) of read-ahead caching, but only for files accessed over SMB.

 

other services:
(Not sure this exisit in unraid though... works in debain/ubuntu...) uriad run on slackware  linux...
 

Solution: Using readahead Service (Linux)

If you want per-file-type read-ahead behavior, you need a user-space workaround using readahead or aio_read via scripts.

 

-Method Debain/ubuntu Preload MKV files using readahead

sudo apt install readahead  # (Debian/Ubuntu)
sudo dnf install readahead  # (Fedora)

Create a script to preload .mkv files into RAM:

find /path/to/media -type f -name "*.mkv" -exec readahead {} +

*Automate this via a systemd(systemVint /etc/rc ) timer or cron job. user script plugin...
 

A Solution: Using ionice and cat for On-Demand Read-Ahead

If you only want read-ahead when playing .mkv files, you can create a wrapper script:

 

(should work in unraid... untested...)

Create a script to force read-ahead for .mkv files before playing:

#!/bin/bash
FILE="$1"

# Check if it's an .mkv file
if [[ "$FILE" == *.mkv ]]; then
    echo "Preloading $FILE into RAM..."
    ionice -c 2 -n 0 cat "$FILE" > /dev/null &
    sleep 2  # Give some time for read-ahead to kick in
fi

# Play the file (example with VLC)
vlc "$FILE"

Use this script to launch video files instead of opening them directly.

 

depends more on what and how the file is being accessed to throw into ram....

11 minutes ago, bmartino1 said:

A Solution: Using vfs_read_ahead in Samba (for network shares)

If you're serving video files over a network (Samba/SMB), you can optimize read-ahead only for .mkv files using Samba’s vfs_read_ahead module.

 

Enable vfs_read_ahead for Video Files example per share... (Unriad has moved these file and edited them its posble to write your own smb conf...
Edit your Samba configuration (/etc/samba/smb.conf) and add:
 

[media]
path = /path/to/media
vfs objects = read_ahead
read_ahead:readahead = 65536

This enables 64MB (65536 KB) of read-ahead caching, but only for files accessed over SMB.

This looks particularly promising. When you say I can restrict this to .mkv files, how would that be done? Wildcards in the path above, like `path = /mnt/user/video/**/*.mkv`?

It would be good enough, even if it isn't strictly for .mkv files, for the read-ahead to apply to everything in the video share.

using samba share only:

vfs objects = read_ahead read_ahead:readahead = 65536

this would affect everything in the share...

You would leverage other samba config stuff:

In Samba, the vfs_read_ahead module does not natively support filtering by file extension. However, you can work around this limitation by using Samba’s veto files option in combination with a separate share for video files.

 

Workaround: Separate Share for MKV Files

You can create a separate Samba share just for .mkv files, which enables vfs_read_ahead only for that share.

Step 1: Create a Directory for MKV Files

First, create a dedicated subdirectory for .mkv files:

mkdir -p /path/to/media/mkv
find /path/to/media -type f -name "*.mkv" -exec mv {} /path/to/media/mkv/ \;

-This moves all .mkv files into a separate folder.

 

Step 2: Add Two Samba Shares

Now, modify /etc/samba/smb.conf:

 

[media]
path = /path/to/media
browseable = yes
read only = no
guest ok = yes
vfs objects = recycle
veto files = /*.mkv/
delete veto files = yes

[mkv]
path = /path/to/media/mkv
browseable = yes
read only = no
guest ok = yes
vfs objects = read_ahead
read_ahead:readahead = 65536

 

How This Works

[media] Share:

Contains all files except .mkv, thanks to veto files = /*.mkv/.

.mkv files won’t show up in this share.

[mkv] Share:

Only .mkv files are stored here.

vfs_read_ahead is only enabled for this share.

 

I would use sym links instaed of moving files...
Alternative: Symlink Instead of Moving Files
 

If you don’t want to physically move .mkv files, you can use symlinks:

mkdir -p /path/to/media/mkv
find /path/to/media -type f -name "*.mkv" -exec ln -s {} /path/to/media/mkv/ \;

 

Then, configure Samba to follow symlinks:

follow symlinks = yes
wide links = yes
unix extensions = no
 

 

 

again, a bit in the weeds at that point...

also others have had issues using veto on unraid:
 

more info on smb conf and veto:
https://www.samba.org/samba/docs/using_samba/ch08.html

27 minutes ago, bmartino1 said:

more info on smb conf and veto:
https://www.samba.org/samba/docs/using_samba/ch08.html

One thing I must confess I'm baffled by is where you find all of this info. When I google with search terms like "smb.conf" and "read_ahead" I find nothing of use, unless perhaps the useful stuff is several pages into my search results. I'd be happy to figure out more on my own with the head start you have graciously provided, but damn, the info is hard to track down for me. I haven't, for instance, been able to find a single example other than the one you provided of a "[media]" section in a smb.conf file to better understand what that whole section is about.

Edited March 18, 20251 yr by RasterEyes

I've built and ran linux samba server when samba first came out as a consultant for a ISP(a good 10 years) and many corporations in my local area. Its Samba Configuration and other i've collected via experiences. Some via the samba v4 docs that may or may not work due to CVE and code mutations.

You could ask AI. it definitely helps... I sent you links for the stuff is there something your looking for specif? as Samba has alot it can do and be leveraged with. TOO much really!

There is a difference between local machine permission and share permission. Leverage samba share permission, we can access and do things.

Like the readahead and veto per share options.

 

https://www.samba.org/samba/docs/4.9/man-html/vfs_readahead.8.html

 

 

Edited March 18, 20251 yr by bmartino1
typo - Data

46 minutes ago, bmartino1 said:

You could ask AI. it definitely helps... I sent you links for the stuff is there something your looking for specif?

Oh, I think I've got enough to go on. I was just curious to understand more so I'm not just blindly following a recipe.

As a human you set me on the path of looking into SMB configuration. I'm not sure, but since I hadn't even considered that as part of a possible solution, I don't know if I'd have asked the right starting question to end up being directed to SMB configuration by an AI.

Now that I'm thinking Samba, I asked this question: "How do I configure SMB to provide read-ahead for a particular share?"

 

...and got this answer:

 

[YourShareName]
path = /path/to/share
read only = no
vfs objects = readahead
readahead = 128  # Number of kilobytes to prefetch (optional, default is 64 KB)

 

...which curiously disagrees on KB vs 512B block size, but, more of a cause for wonder, starts with "[YourShareName]" rather than "[media]". I guess you meant "[media]" as a sample name, whereas at first I was thinking "[media]" was a particular named subsection of smb.conf for a particular purpose, not a share name.

I was also hoping to figure out on my own, without being a nag, what form the path here would take ("/mnt/user/video" perhaps, starting at the file system root?) on my Unraid system, and whether or there might already be a "[video]" section in some conf file somewhere set up by Unraid when I created my share, and if I would be running any risk of inappropriately overriding that if that's the case.

The devil is can be in the details when wandering outside of one's own expertise, and SMB config files are definitely foreign territory to me.

Edited March 19, 20251 yr by RasterEyes

I poked around some more to answer some of my own questions and found this at "/etc/samba/smb-shares.conf":

 

[video]
        path = /mnt/user/video
        comment = 
        browseable = yes
        # Secure
        public = yes
        writeable = no
        write list = foo,bar
        case sensitive = auto
        preserve case = yes
        short preserve case = yes
        vfs objects = catia fruit streams_xattr
        fruit:encoding = native

 

Which makes my next question how (and where? in a different file) I modify this in a way that both doesn't conflict and is preserved between reboots.

in unraid you can add that to the extra samba config.

if you have a share already enabled called video /mnt/user/video

you will need to disable the share

 

then stop the array.

web ui > setting > samba Extra

 

 

and paste your custum share.

 

29 minutes ago, bmartino1 said:

web ui > setting > samba Extra

 

 

and paste your custum share.

 

And even though that's a single line, I can paste in a multi-line config? Perhaps like this?

 

[video]
  # Do I repeat the path below, and everything else like security settings, or is that inherited?
  # path = /mnt/user/video
  # Do I repeat what was below, and then add on read_ahead?
  vfs objects = catia fruit streams_xattr read_ahead
  # vfs objects = read_ahead # Maybe this instead of the above?
  readahead = 65536

I have no idea if this would be treated as a total replacement of any previous [video] section, would inherit from it, appends or replaces with things like "vsf objects"... sorry this is so unfamilar and confusing to me.

Edited March 19, 20251 yr by RasterEyes

yes you would paste the entire share config setting and all in the extra box.

all of it

[video]
        path = /mnt/user/video
        comment = Manula SMB Share
        browseable = yes
        public = yes
#        writeable = no
#        write list = foo,bar
        case sensitive = auto
        preserve case = yes
        short preserve case = yes
        vfs objects = catia fruit streams_xattr read_ahead
        fruit:encoding = native
        guest ok = yes
        read_ahead:readahead = 65536

 

otherwise you can repalce the smb.conf and use a override smb via include and put your share setting in the included file as outlined in:

 

Edited March 19, 20251 yr by bmartino1
Data

On 3/18/2025 at 10:13 PM, bmartino1 said:

yes you would paste the entire share config setting and all in the extra box.

I wanted you to know it's working great. With my array still steadily copying terabytes of data, in reconstruct write mode so every disk is spinning and busy with that task, I was able to watch 4K video steadily for the length of an nearly hour-long show without the slightest hiccup.