I run Roon on my Syno DS1520+ and I could install a SSD cache memory module.
Is it feasible to keep the Roon database then in this SSD cache? Or does the database needs to be on one of the 5 disk bays I have?
Does this cache volume appear as a folder or partition in the file explorer and can it be used as a normal folder offering another 32 or 64GB of free space? That is a necessary condition for telling roon to run the database on that one.
Alternatively, you can configure your SSDs to act as a cache, which allows you to store your database on a spinning media-based storage pool and have the SSD cache sit in front of it. That’s what I do. If you install two SSD modules, you can run them in Raid 1. You can also choose to pin file system metadata to the cache, which can also significantly increase performance.
@hallo_leo, I don’t want to steal your thread in any way, but I have an additional question for @gTunes. The answer to that may also help you.
I have configured my Synology DS920+ exeactly the same way. It works fine.
I do not understand what you mean by “to pin the file system metadata to the cache”. How did you configure this in practice?
Hi, @Alfred_van_Hoorn.
Within Storage Manager, if you select the storage volume your SSD cache is attached to, you should see something similar to this at the bottom of the page.
If you select your language’s equivalent of “Configure,” you should see something like this:
That’s all there is to it 
Hi, @gTunes,
Thanks for the explanation!
For me, no menu item “Configure” is shown at the SSD cache. 
I think it is because my drives are formatted with EXT4 instead of BRTFS like yours.
Again thanks for you reply.
1 Like
If you install an M.2 SSD in your 1520+ you would need to mount it as a storage volume for the Roon database to be hosted there. Synology do not support this on the 1520+, but there is an easy-to-use script on github that will fix this on the 1520+ and allow you to configure the M.2 SSD as a storage pool via the DSM GUI. I tried this on my own 1520+ just out of curiosity and it worked, though my ROCK NUC is my Roon daily driver.
2 Likes
Well this is new to me. Thanks for sharing. Interesting.
I’ll confirm, I have Roon database on spinning disks, but enough M.2 cache to hold it (and then some) and performance is fine on 1522+.
1 Like
Cool! Do you know the URL of the gist?
I just want to clarify: You have the M2 SSD as cache not as volumne, right? So the Roon db is on a HDD, but is automatically held in the cache?
Also, I’m curious: How do you know that the Syno really caches the db (and not other stuff)?
Yes:
Oh, I know that it does cache other stuff, it is its purpose after all. But by design it does not store large files you access sequentially (e.g. your music files) but does cache small(er) files you access randomly, which is very much the usage pattern of something like Roon’s DB. It also stores all file system metadata.
With usage stats like these:
(this is with a 50+K tracks Roon setup) Roon, for all practical purposes, is running from SSD, and an M.2 rather than SATA SSD at that, with room to spare.
You could get a smallish SATA SSD that would fit in regular disk bays to run Roon from, but then smaller SSDs last less than larger ones, and that would make only Roon run any faster. With a cache, everything using random I/O is accelerated.
IIRC, the 1522+ does allow partitioning M.2 drives and only using what’s really needed for the cache, and the rest for storage (there is even a rather long-running process that analyzes cache usage and produces sizing recommendations) but I don’t really have anything else that would benefit from being stored directly on SSDs that could not be served by a large enough cache just s well.
1 Like
just search on github synology m2 and you’ll land here. One issue to look out for is potential for a DSM update to break the M2 volume, but there is a patch script for that scenario that can be added to your DSM task manager on boot events.
1 Like
As noted above in the thread, I do the same thing you do with respect to cache vs. volume.
I assumed it’s a simple read-through (and optional write-through) cache operating at the block, not file, level. If that’s the case, there’s no distinction between large and small files, it’s all just blocks and some MRU/LRU logic/queue/whatever to determine what to purge when under pressure.
In any case, your cache hit rate (and mine) are both so high that we can pretty safely assume that everything our Synolgys have interacted with over the past month is sitting in our caches
@hallo_leo - two things I want to mention:
-
if you’d like to operate in “read-write mode” vs “read mode”, I strongly recommend buying two identical SSDs and running them in a RAID 1 mode. This is an option when you set up the cache.
-
As noted above in this thread, if you format your cache drives with BTRFS, you can set an option to pin file system metadata in the cache. It seems that you possibly can’t do this if you format your drives as EXT4, so you may want to take this into consideration.
I personally strongly prefer this cache-based approach to a dedicated SSD volume. It’s a good route to go.
1 Like
Per SSD Cache | DSM - Synology Knowledge Center it’s not so much the file size as whether random or sequential commands are issued…
Yup.
I think it even requires having 2 (or more, if supported) sticks to enable write part of the cache…
With a correctly sized (or oversized) cache it’s certainly more flexible, and improves performance of almost everything on the NAS, not just Roon.
Thanks for this reference.
That page confused me because it describes a toggle for disabling caching of sequential i/o that I couldn’t find. It took a while to figure out that you referenced the DMS 6.2 docs. The DMS 7.2 docs don’t mention that toggle - I think it’s been removed.
I wouldn’t have turned it off anyhow. Caching sequential i/os is generally not particularly helpful because lower layers (the disk itself and probably the file system and possibly the OS) are already doing a combination of over-reading and reading ahead. So if you’re in an environment where space in your SSD cache is at a premium, you might as well let the performance benefits come from other layers of the stack.
But, if you’re like us, and your entire system is ridiculously over-provisioned, and your cache is barely populated, you might as well just let it get used for everything
Yeah, I don’t have that switch either, but at least here they are saying something about the cache implementation.
Caching sequential requests is generally useless, so maybe they just removed the option altogether and turned it off, unless you just keep re-reading the file, in order, over and over, which is unlikely.
Looking at my cache usage (and that’s for everything on the DiskStation, not just Roon specifically) and the library size, I think even the smallest SSD you could get for a Synology would be more than sufficient for most common library sizes…
1 Like
Or they figured out that it was more trouble than it was worth to differentiate between request types. It’s almost certainly easier to build a cache that doesn’t care whether the i/o is one or the other. The write path certainly can’t care because a write is a write - the cache always has to minimally be purged but in the case of a read-write cache, has to act as a write through.
If it’s me…I’m building the cache to not care and then proving that it needs to care before doing anything different. If I figure out that it needs to care because often the cache is full of useless stuff, I’d try to make it adaptive rather than just off for sequential. I don’t think that would be all that hard. I already have a few ideas for how to a) decide to cache or not to cache at the time of read based on the fullness of the cache and b) to retain whether a block was read one way or the other in cache metadata and factor that into my storage pressure algorithm
Well, caching is the second hardest problem in computer science (naming things correctly is the first)
In any case, the point remains that for library sizes that are actually feasible on a NAS box, Roon with the database on spinning disk and a read/write SSD cache will perform as well, if not better, than Roon with the database on SSD, and one will get a performance boost for other applications as well.
Of course there are caveats about maintaining the cache properly (at the very least, if one removes it, to remove from in the DSM Storage Manager first and wait until data is fully written through to disks), but generally, and especially if one has a smaller Synology model (i.e. <= 2 bays) using a cache makes IMO far more sense than wasting a bay on a disk dedicated to just the Roon database.
4 Likes
It’s always a good idea to run the SSD Cache Advisor in Storage Manager to verify the benefit it will provide. It’s been a while since I did this, but the last time I did, it didn’t think I would benefit.
1 Like