SSD

I can think of a big reason ... If I am writing in turbo mode to disk1, and want to play a movie from disk2, disk2 is going to be very busy and the movie will stutter.. If fact the contention on disk2 might seriously slow down the writes to disk1 in this scenario. Turbo write is bad for arrays that do multiple things at once. If I am writing in regular unRAID write mode, the write to disk1 is only affecting disk1 and parity, and reads from disk2 are going to be unaffected.

I'm not sure it is so much the number of times spinning up and down, as the temperature variations that impact longevity. (Guess they are somewhat correlated.) For that reason, I keep my spindown time set to a relatively high number - 5 hours. Based on my usage pattern, I have found that is a good number and avoids spinning up a disk more than once a day in most circumstances. I think its better to have it run that long than to have it spinning up and down 3 or 4 times during a day and having the associated temperature fluctuations.I Jeff.I think the default is 1 hour. I very much recommend others to adjust based on their usage pattern, regardless of turbo write setting. My opinion is that turbo write is a very good thing for initial loads, file system conversion (from RFS to XFS), backups, and other lengthy disk write operations. Those uses could save hours or even days in some cases. But for everyday I wouldn't use it, even if all the disks were already spinning. Maybe I'd feel different if I had only a handful of drives - but creating the level of activity on the server to write a file and save a few seconds or even minutes here and there seems overkill. My server is being used more and more for varied tasks, and I really enjoy that my accesses only minimally inconvenience each other. I can't remember last time I was drumming my fingers waiting for a write to finish. I do find my RAID0 parity setup, along with unRAIDs tuning that provides a nice burst of speed when a file starts copying, currently keep everyday performance very reasonable.

Just converted over from LimeTech docker to LSIO, and expect the log messages below are associated with a new version of Plex. Never saw such messages before.. Suggestions?

RobJ - It is impossible to make anything foolproof, because fools are so ingenious. -Anonymous

I added this to the top of my (a bit old) guide that is pinned saying that it is newer. Done - only goes to top based on update date/time. But it is sticky.

Here is some bed lecture for you https://docs.docker.com/engine/tutorials/dockervolumes/ It's possible, but if it's user and backup friendly is another thing. This is not exactly what I envisioned. I was thinking that the mounted volume would exist outside of the docker features, and would be mounted and symlinked to "Metadata" inside the following path: appdata\PlexMediaServer\Library\Application Support\Plex Media Server\Metadata I guess what I was really asking is what filesystem would I use that would be friendly to this type of content. I see btrfs supports compressed volumes and ext4 gets good marks for high performance with lots of files, but I see nothing about compression. But I'd like to squish the slack out of all the file allocations without causing Plex to slow down to a noticeable degree. Looking at BTRFS, looks like it is shrinking each file. Not sure that would help so much.

This is similar to what I experienced. Off by a couple gig.

Sorry if a little offtopic for LSIO support thread, but thought I would ask here. Question about plex metadata storage. Plex creates a deep structure of tiny files to store its metadata. This makes backups and file searches lengthy, consumes an inordinate amount of disk space, and confuses Windows. I was wondering if we could create an image file (similar to Docker.Img) that could be mounted and used for this metadata. The file itself could then be copied in one step. Not sure if there is a compressed filesystem structure that could be used that is well-suited to a ton of tiny files. Thoughts?

This!

I believe I found where the problem is. Somehow, a vdisk1.img is copied with a much bigger size: root@UnRaid:~# ls -l /mnt/disk4/vm_backup/Windows\ 10\ Workstation/ total 398458884 -rwxrwxrwx 1 root root 408021893120 Mar 1 2016 vdisk1.img* root@UnRaid:~# ls -l /mnt/disk3/vm_backup/Windows\ 10\ Workstation/ total 40994716 -rwxrwxrwx 1 root root 408021893120 Mar 1 2016 vdisk1.img* I know that KVM/Qemu sizes the vm disk dynamically, so that could explain why on disk3 the actual image size of 40994716 is much smaller than the allocated size of 408021893120. However, I cannot explain why the copied image file is not the same size. Would you expect this disk image to be 400G? That is frickin' huge! 40G seems more normal. Is the VM running? I would stop the VM and recopy this file over. Good catch! This is the type of thing you are looking for when you do sanity checks doing the XFS conversion.

looks pretty solid, I might pick up 3 of these Did you read the one scathing review? I'll often discount a single bad review, but this guy gives details that make it seem very believable. I'd stay away. And it is not cheap. Look at THESE. I can vouch for them - have them in primary and backup servers. Flawless locking mechanism. Replaceable fans. Outstanding airflow. Little screws slightly annoying - but I'd buy these all day long. 10/10 Want cheap. I bought a few of THESE to use to mount external to my case. They are 4in3 vs 5 in3. Do I love them? No. But they work. I find I have to give the cage a little shove after the latch clicks to get good connection. But since I figured that out, I'd give them a 7/10.

Depends. Different allocation sizes, different reserved space, different filesystem Most likely what you are seeing is perfectly normal. A different mix of file sizes will yield a different result. Although I agree with jonathanm in theory, I believe that your numbers are too far apart for that to be the reason. If these two disks are supposed to contain exactly the same files and data, 1.77TB vs 2.13TB = 360 GB. When I did my array, I remember sometimes free space was bigger, sometimes less. But it was always numbers that you could call rounding error (a few gigs maybe). This is much larger than anything I saw. I think something is wrong. Can you compare file counts? Or confirm that you have data on disk4 that is not supposed to be on disk3?

Awesome! Really like this video. Very practical. A ton of unRAID users will learn a lot.

Done - with the link in the other post, this will be easy enough to find.

I created a thread with a link to the wiki instructions, and renamed this thread to add "(discussion only)" to the end. The wiki thread does not allow posting (it is just a short statement and a link to the wiki article). Format XFS on replacement drive / Convert from RFS to XFS

The following link contains the current best practice for converting your array from RFS to XFS, based on lessons learned and lengthy discussion in the discussion thread (also linked below). Thanks to the community for the conscientious updates to improve the efficiency and safety of this process. And to RobJ for gathering all of the best ideas, and adding to them himself, and putting them into the wiki! This thread does not allow posting so that it is easy for users to locate the actual procedure. File System Conversion (link updated (again)) Here is the original thread where you can continue to post and discuss the process and ask for assistance with specific situations. Format XFS on replacement drive / Convert from RFS to XFS (discussion only) (link updated) Cheers!

Parity will take care of itself. To unRAID, a disk is a string of bits. So when you format the disk, to unRAID you are just changing some of those bits. Parity will be kept straight throughout the process. Share include/exclude disks settings need to be revisited after the process. Depends on how much you've customized them. I think even share settings survive a new config. So you'd need to adjust them regardless. No need to do a new config. In fact, the whole idea is to do all this within the protected array.

I would suggest freeing up one of the 3T drives by copying to other disks. Now you have an extra disk in the array. You can format it to XFS and do the leap frog (I like that analogy ) to do the other disks. When you're all done you can re-balance - that's up to you.

Very much looking forward to that!

Its related to Plex because Plex is hammering the cache drive during transcoding. And that hammering increases both bandwidth transferred and power consumed which is going to aggravate any small flaws in connectors / splitters / etc. I have a particular drive here that only likes being in a certain bay of the 12 bay hotswap case. Any other bay and all the little manufacturing tolerances are just out enough for that drive to give the same errors under load. All the other drives work perfectly everywhere... You're approaching but not quite at six sigma.

The drive dropped offline. OS tried to revive it, even drop its link speed, but was unsuccessful. Likely a bad or loose cable (Sata or power), or something more serious wrong with the drive. Jan 22 13:57:51 Beall kernel: ata7: hard resetting link Jan 22 13:58:01 Beall kernel: ata7: softreset failed (1st FIS failed) Jan 22 13:58:01 Beall kernel: ata7: hard resetting link Jan 22 13:58:11 Beall kernel: ata7: softreset failed (1st FIS failed) Jan 22 13:58:11 Beall kernel: ata7: hard resetting link Jan 22 13:58:46 Beall kernel: ata7: softreset failed (1st FIS failed) Jan 22 13:58:46 Beall kernel: ata7: limiting SATA link speed to 3.0 Gbps Jan 22 13:58:46 Beall kernel: ata7: hard resetting link Jan 22 13:58:51 Beall kernel: ata7: softreset failed (1st FIS failed) Jan 22 13:58:51 Beall kernel: ata7: reset failed, giving up Jan 22 13:58:51 Beall kernel: ata7.00: disabled

Yes it will pull down the latest build, unpack and install it in the docker, then run some user-scripts. It will take a few minutes, give it some time. This is an advantage some of LSIO dockers. You can update them yourself just be restarting them. Or you can use a specific version by telling it what version to use. That and the awesome support provided by the group of devs. The unRAID forums are a magical place!

I installed the LSIO docker and it wanted to install Plex. I guess the docker doesn't have any version installed. I was expecting it to just come up, but now realize that this should have been expected. i put the old docker back in place for now.

I am considering moving from the Official LimeTech Plex docker to the LSIO version. Would it be a valid strategy to stop the LimeTech docker, install the LSIO version (providing equivalent mappings), and just start it up? I believe at this time both the public and plexpass versions (1.3.3.3148), and that would mean that I should be able to run one or the other dockers seamlessly. Once convinced that the LSIO version is running properly, I can delete the old Plex Docker. If that is not a good method, and there is another documented process, point me in the right direction. I did some searching and didn't find anything specific. Thanks!

Wow - hard to believe 29 pages of discussion about converting to XFS. It was almost exactly 2 years ago I wrote the initial comprehensive guide to convert. Thanks to RobJ, gary, trurl and the rest of the crew for continuing to enhance the process and supporting users enhancing their servers. There was quite a debate about the value of converting when XFS first became an option, with reasons on both sides of the aisle. But at this point, XFS is proven. There are compelling reasons to convert, and I would encourage virtually all users to upgrade to XFS, at least on their primary arrays. Here are some of the reasons ... 1 - Reiserfs (RFS) is not being actively supported or enhanced. Just enough is being done to keep the lights on. We've had one situation where a Kernel update required a small update to RFS. The fix was not made properly, and allowed data corruption that made it into the golden version of Slackware Linux and unRAID. The corruption was insidious and did not just affect new files written to the disk - it could just as easily corrupt old files. Several unRAID users were affected (due to the nature of the issue, knowing if you were impacted and if so, exactly what files were involved, was virtually impossible for most people. I cannot say with certainty that I was not affected). The problem was fixed pretty quickly, and no new issues (that we know of) have occurred, but given the population using RFS is getting smaller and smaller, the testing of new updates will be less and less of a priority. RFS is not a good place for your family jewels IMO. 2. As one who has been around unRAID for nearly 10 years, since unRAID 2, I can tell you that unRAID always had its quirks with RFS. I had inconsistent performance, timeouts, and a number of oddities, especially as disks get full. As disk sizes grew to 1T, 2T and beyond, the problems got worse, and eventually problems were happening with half full disks. I can say that since moving to XFS, I have had NONE of these annoying issues. My XFS powered array is rock solid, except for the very occasional real disk problem which unRAID handles quite well. 3. Everyone uses their servers a little different, but if you're like most, your unRAID server is getting more and more data to hold and stuff to do over time. Initially mine was a toy in my basement, and wife could have cared less if it was up or down. But now it is an indispensable tool for my family. Converting to XFS takes some time and attention, but next month, or next year it will be worse. And imagine hearing that RFS has started corrupting people's servers. That is not the time you want to begin thinking about your update journey. How'd you feel about shutting down your server for a few weeks while it gets sorted? Two years ago I might have agreed that there is no rush, wait for an opportune moment. But at this point, I suggest you get started now. 4. Dual parity is a nice feature, but it would behoove you to upgrade before installing that second parity drive, which just makes the upgrade process more complicated. 5. Maybe low on the totem pole, but the author and namesake of RFS, Hans Reiser, brutally murdered his wife and is rotting in prison. He's a real winner - having just lost a lawsuit from his children. Read about him HERE. I'd just as soon not use his file system, and let it fall into obscurity, with its user based shriveling to zero. Good luck everyone! I am most easily reached via PM, as I am not able to monitor these forums like I once did. Enjoy your arrays!!