I noticed a Plex share (hidden) on vol1. Probably made when installing Plex on the NAS. Can I migrate this to Vol3 by simply editing the properties of the share? Will Plex still work after this?
It worked for me for all other shares (like homes, music, video etc.) but I am uncertain if this works for Plex as well. (I want to delete the volume it's on, since it's a basic disk and not an SHR volume)
OK. Plan B is a re-install of Plex on another volume and then overwrite the installation with the old database. Since everything will be lost anyway, it's worth a try.
So how can you access the hidden plex location? As it’s not visible in Windows. I have the same problem. I can see it only when connecting to ssh on volume1? Attemps te access the folder are denied.
@trumpy81 I have just purchased a SSD for PLEX.
Is this still a issue? not possible to install Plex to anything other than volume 1?
I believe I can install Plex on any volume today? correct?
My plan is to install it to a new SSD volume and then restore the Data to this new volume
Best regards
Casperse
UPDATE:
Q27: How do I install Plex on another volume?
Note: Since Plex version 1.7.0, you can now select the volume to install on when you manually install Plex. All of the Plex program files will be saved in a hidden folder on the selected volume. Also, the Plex shared folder will be saved to the volume you selected at the time of the installation.
If installing Plex version 1.7.0 or higher, follow these steps:
Uninstall PMS
In DSM Control Panel > Shared Folders, rename the existing Plex Shared Folder to a different name (EG: PlexOld)
Create a new Plex Shared Folder on the desired volume and give it read/write permissions for admin and Plex
Move the contents of PlexOld to the new Plex Shared Folder using File Station
Delete the PlexOld Shared Folder in DSM Control Panel > Shared Folders
Install PMS version 1.7.0 or higher. It will automatically find the Plex Shared Folder in its new location
I am not going to change any of my existing media volumes (RAID 6)
Only the Plex installation to a single SSD (JBOD)
So I have planned on creating a 3 month backup schedule for data on it to the master RAID volume
In case the SSD crashes I have the option to restore a 3 month old backup
But I actually thought I could just move the shared Plex folder to the new volume and that would be that.
But Reading your excellent FAQ I believe I can do this instead:
Disable Empty trash can on server
Stop Plex server
Copy existing Plex shared folder with a new name OLDPLEX to the new Volume 6 SSD
Uninstall Plex on Volume 1 - Delete any old Plex folder on Voulume 1
Rename OLDPLEX folder to Plex (User rights for admin, plex etc)
Delete XML config file
Install Plex to new location Volume 6
Start new Plex server
No change to media links and shared media folders, so wouldnt this be OK?
BTW: I have also planned to moved my Docker folder hooping for quick WEB access :slight_smile.
I Beleive that Photo backup and restore with Hyperbackup will include the whole Photo folder so that seams to be a No GO!
Sofar I can see my only option for one SSD drive is basic configuration not JBOD, and I also found a very long article about why btrfs should be the right choice for SSD (I bought a Samsung 860 Revo 1TB drive on the synology supported list, so TRIM should not be a problem)
I Really hope I can see a noticeable performance gain browsing Plex and starting transcoding…
BTRFS is a journalling and metadata recording FS. It will generate more wear and tear on the SSD than ext4. The SSD has a finite TBW (Total Bytes Written). If the FS is recording every time you access it, that’s wasted utilization. I ask “Why waste it?” If it was a long, drawn out reason as to why it’s better, do you really need that much of a sales job?
Ext4 also journalling but it doesn’t record metadata and isn’t a layer of NAS in the FS itself.
I have two Samsung 860 EVO (not Revo) 1TB. Trim is required (because you’ll be writing to it) but will be done by DSM for you automatically on a periodic basis to keep it wearing evenly.
Moving the Plex share is trivial on DSM. I’ll write out how I would do it. Please ask questions and adjust as is appropriate for you.
Assumption: DS1815+ with 7x 8TB, RAID 6 volume 1
Insert Samsung into bay 8 and create as JBOD volume, formatted EXT4
Stop Plex
Rename existing Plex share to OldPlex
Create new Plex share on Volume 2 (SSD volume)
Assign plex as owner of the share in File Station
Using Filestation, Drag & Drop the contents of OldPlex, COPY to Plex
Upon completion, verify plex is owner of Library and tmp_transcoding folders.
Package Center - Uninstall Plex package
Manual Install Plex again. - Triggers the installer to run again and verify ownership, ACLs, and location info .
Sorry I also have bought the EVO not the REVO (To big a price difference for me)
I had to manual enable TRIM and select a schedule (once a week) for the new drive in the UI DS3617xs and I don’t have any option to select JBOD volume with a single drive only option “Basic”?
Hmm here is what I found on Btrfs (I also have this on my Raid 6 volume for pure storage, but that’s mainly because I like the fast clone option and the snapshots option - also to many ext4 crash and restores…so wanted to try something new)
Btrfs
Ext4
Btrfs it actually is a pretty solid file system for basic usage. especially when talking about solid state > drives. The main reason is that Btrfs doesn’t journal unlike some other popular filesystems, saving precious write space for SSDs and the files on them.
The Btrfs filesystem also supports TRIM, a very important feature for SSD owners. TRIM allows for the wiping of unused blocks, something critical to keeping a solid-state drive healthy on Linux. Filesystem TRIM is supported by other filesystems. This really isn’t the main reason to consider Btrfs for your solid-state drive when using Linux.
A good reason to consider Btrfs is the snapshot feature. Though it is very true that the same thing can be accomplished on other file systems with an LVM setup, other filesystems do not come close to how useful it can be. With Btrfs, users can easily take snapshots of filesystems and restore them at a later date if there are any issues. For users looking for the best SSD support on Linux, it’s crazy not to at least give Btrfs a look.
However, the reason that Ext4 it is not #1 on this list is for a simple reason. Extended 4 is not designed with SSDs in mind. It is true that it has file system trim support (a critical SSD feature), but outside of that the filesystem was never designed for this use case. Why? It uses a filesystem journal. This means that the filesystem is constantly writing logs down and informing the system of every single change. This can quickly wear out the limited write-space on an SSD running Linux.
Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.
But you might be right? First SSD in a Synology NAS (Was also looking at the SSD NAS Cash option that would require 2 x SSD, but since PLEX is what I aim to increase performance on I dropped that again)
fstrim is supported on ext filesystems. It was there first. I’ve not looked but suspect it’s also supported for xfs filesystems since xfs & SSD usage is a big deal in enterprise environments where multi-TB SSDs are a requirement.
Reference: My fedora man page opening clauses. fstrim is auto-enabled at installation.
NAME
fstrim - discard unused blocks on a mounted filesystem
SYNOPSIS
fstrim [-a] [-o offset] [-l length] [-m minimum-size] [-v] mountpoint
DESCRIPTION
fstrim is used on a mounted filesystem to discard (or "trim") blocks which are not in
use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provi‐
sioned storage.
By default, fstrim will discard all unused blocks in the filesystem. Options may be
used to modify this behavior based on range or size, as explained below.
The mountpoint argument is the pathname of the directory where the filesystem is
mounted.
Running fstrim frequently, or even using mount -o discard, might negatively affect the
lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient
trimming frequency is once a week. Note that not all devices support a queued trim, so
each trim command incurs a performance penalty on whatever else might be trying to use
the disk at the time.
Given how Synology does JBOD / Basic single-drive volumes, I can understand you might need to take a few non-standard steps (they do try to make big volumes for us not little ones)
You should look at how BTRFS works. It’s COW (Copy On Write). It looks good on paper but it fails miserably in practice. I will find the forum posts here were folks have lost their BTRFS media volumes and Synology could not recover the data.
This is a critical disqualifying point in my mind. Please do read their latest ‘updates’ (Aug 2018). They are still adding new capabilities which already have existed in other file systems for a very long time.
I submit to you It’s not ready for prime time by any measure or stretch of the imagination.
The Btrfs code base is under heavy development. Not only is every effort being made to ensure that it remains stable and fast but to make it more so with each and every commit. This rapid pace of development means that the filesystem improves noticeably with every new Linux release so it's highly recommended that users run the most modern kernel possible.
Synology does not use the ‘most modern kernel’. They roll their own.
admin@moesern:~$ uname -a
Linux moesern 3.10.105 #23739 SMP Tue Jul 10 00:16:57 CST 2018 x86_64 GNU/Linux synology_avoton_1815+
admin@moesern:~$
Do you really want to entrust your data to a specification which is not stable and proven? I don’t and I won’t.
That ship has “sort off” sailed for me, since I have a very very very large RAID 6 btrfs volume, and not really the storage capacity to move my data while I recreate my volumes. (Also purchased a DX1211)
But I have had these volumes since 07.2017 and I have received some btrfs updates from Synology during the way, so for the time being I have to trust that btrfs/Synology will keep my data safe and they know what they are doing…(Knock on wood)
I do have the option to redo the SSD though… Is Basic = to JBOD? I guess not…sigh!
(Yes they greyed it out in the wizard and requested 2 drives to format the volume, so I went with Basic)
I guess I have to perform some hack to get it formatted in JBOD as 1 drive?
You do know that you are ruining any chance of me getting some peaceful sleep now, right?
a SSD ‘Volume’ in the Synology world is two SSDs (mirror RAID)
In their context, Basic = JBOD. If it doesn’t give you read/write on a single physical media, then you can’t have what you want at all.
To format it, you probably have to go to the Custom / Advanced and hunt. They won’t make it easy or obvious. They do it that way because most owners want an appliance. (turn it on and it just works).
“Basic” does provide me with a disk I can create a volume on.
Just not sure what it is? (They write that I can change the basic to a Raid format later by adding a extra drive and changing the format, so it must be some “Raid”)
Anyway it worked Plex and my Dockers are now running from the SSD and I can see a visual performance increase just browsing movie posters, scrolling down, so now I just have to make up my mind if I should start over and create a Basic ext4 volume?..
Anyway thanks for the input even if it wasn’t what I wanted to hear… LOL
It’s normal to upgrade a Single disk to a Mirror RAID (did that with my QNAP M.2 boot SSD).
Given you’re so far from port, you should probably sail with BTRFS Cruises until the next port.
I started with a Syno DS1813+, outgrew it in 3 months.
When the DS1815+ arrived, I knew it was going to be insufficient but at least a tolerable quad core.
When the TVS-1282 came out, I jumped on it. 8x 3.5", 4x 2.5", 2x M.2 with 3 PCI-E slots. (Yes, I got the i7-6700 haha).
Had I waited 3 months, I’d have been able to get the KabyLake (i7-7700) 1282-T2 which does HEVC. For me, that’s ok. I have the ATV 4K and everything else does 4K natively so no transcoding of video. I have all the punch I need for audio if/when needed.
So just a small update to anyone else who finds this posts and have a large volumes on a Synology NAS using Btrfs…
I called around to IT companies that I have friends that work with servers.
And I know have bought some really large Synology enterprise servers with hundred of TB data (Rack mounts) and I asked what they are using ext4 or Btrfs? And sofar all of them is using Btrfs and haven’t had any issues with them since starting using it.
So I am not saying this isn’t under heavy development and this is a risk using it. Just saying I sleep much better knowing that it’s not just me a Home user who went for this option , and that Synology must have a very high interest in making this stable and dependable, or they will start loosing market shares very quickly!
https://www.synology.com/en-global/products/series/xs
I went for the DS3618xs instead of the RS3618xs (Total overkill I know, but wanted a solution that could grow over time with many drives (12-24-36) and low power bill, low noise level and the form factor. I also really like the DSM UI and the rapid development of new features and apps (Btrfs excluded!) Sofar the NAS is rock solid and very fast, so I can’t complain. Oh and all XS series have great warranty they express ship replacement parts
But I do envy the many options QNAP owners have to configure their NAS! and I have many friend that only use QNAP or only Synology but I think it’s really like people choosing between android or iPhones
BTW One thing which I think could be a Plex issue? and have to ask you about
I am getting notification that my Plex server access is down from Tautulli and I can see that its wrong?
Some have stated that Plex changes to their servers is cauing this “glitch” but its driving me nuts
So have you heard anything about this?
In almost all the cases where Tautulli reports ‘down’, it’s been on their end. It’s a difficult API to keep in sync with so I am not faulting here. It might just be a step behind.
I’ve not heard of anything myself but I am so deep in NAS platform alpha work and the upcoming global beta of something much bigger that I’ve not had time to follow other things.
They are Consumer, Small & Medium business. Netapp, EMC, and Pure Storage are real Enterprise solutions. As many say, Synology is consumer oriented when calling them. Call any of the above and it’s a whole different world.
Really nice GUI. It’s very user-centric. If you want to make it easy, they have NAILED it.
From the technical perspective, they’re behind, far behind. For all those reasons I left it. I owned the DS1813+ and had outgrown it before it arrived. I had outgrown the DS1815+ before it was announced. I’m about to divest myself of the second one.
If they would a change a few (relatively) simple things:
Make BTRFS an optional, not the default. It’s a dying file system.
Update the damn hardware.
2a. It’s using single path infiniband for your expansion. Talk about cheap and slow. Why?
2b. Stop using seriously dated Xeon processors which are cheap by the tray. Provide the customer with options and make cooling Active. (add a fan there)
Drives are connected over port multipliers. Look at the kernel device output and see how they’re really connected. Prime example. Run I/O to the main array and concurrently start i/o (raw read) from an external device connection. You’ll see the main array data transfer rate drop. Any Xeon can keep up with CPU demand so the only conclusion is I/O bus congestion.
Regarding #3 above, I offer this:
Raw read from drive 1 and raw read from drive 8 , machine completely idle.
All drives are WD Red Pro 7200 6TB. Drive 1 performs exactly as expected. Drive 8 pays the penality of being run through the multiplier. Both drives 7 and 8 suffer this penalty.
admin@moesern:~$ sudo dd if=/dev/sda of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 93.0236 s, 225 MB/s
admin@moesern:~$ sudo dd if=/dev/sdh of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 155.408 s, 135 MB/s
admin@moesern:~$
If this were addressed with CPU choice (e.g like QNAP does), it would seriously realign my perspective. At this point, I respectfully submit they’re milking an architecture and style which they believe justifies the premium price. Software is only part of the game. If the hardware can’t keep up then why have it. Seriously, 2-3 days to reshape an array? My QNAP can reshape / scrub a larger array in 15 hours.