RobJ

Please see Need help? Read me first!, and attach the diagnostics zip. Actually, it would be good to see both the diagnostics when it fails and when it works, for comparison.

No

Yes, and parity.

Sparkum, it's really important you use the exactly correct command, and it's really important you know exactly what the file system is that you should fix, because if you use the wrong one, you can damage things even worse. All 3 commands you tried above were wrong! This is not the place for trial and error methods. Please, take the time to read the wiki page more thoroughly!

If you don't have any VM's, then no, no special changes needed. It's always wise though to make a copy of your drive assignments, just in case. If you do have VM's, they will probably need some adjustment.

Dan, I have to agree with johnnie.black. For whatever reason, users just do it. They format with UD and expect to add it to the array, and are shocked when it doesn't work. I imagine some do it from ignorance, but even so, it should still work. Others do it intentionally, perhaps as part of an initial data migration strategy - preclear and format a set of drives, take them to another system to fill with data, then bring them back to start an array. Others don't intend to do it initially, but may later change their mind and decide to add the drive to the array, for better fault tolerance perhaps. After all, they think, it's already formatted with XFS, so it should be easy to add. I don't know the reasoning for sector 2048, so I may be wrong, but as far as i know, sector 64 is just as optimal as any other optimal starting sector. I think it would be good for unRAID to be more flexible with what it accepts and can work with, but for now, it's the gorilla, and I think it would be wise to conform to what it wants.

just like all the other ones, via a LSI 9300-8i Host bus. Although the new drives are with two new Host bus adapters that I ordered. Perhaps there is a driver issue there? Please see Need help? Read me first!, and attach the diagnostics zip.

Me neither. Apparently it only shows up for mere mortals. Oooooh ... Does this mean I'm immortal too?!?!?

I can't help with the compiling, but if you contact Tom at [email protected] and specify what you need and the code you have found, he will probably add support to an upcoming release.

I wasn't sure at first why you thought that, but then figured out you must think that unRAID always knows what's on each disk, even after being removed from the array. When you add/assign a disk to the array, unRAID does not know what is on the disk, whether it's empty or has data, and if there's data what file system it is using. And worse, when this was written, the file system was not cleared for an unassigned drive, so that if you unassigned a Reiser drive at Disk 10, then assigned an XFS disk there, it would still be marked for ReiserFS, until you manually changed it. I suspect recent updates have changed that, but it would be marked as Auto, meaning it's supposed to try and figure out the file system on next use. In the past, Auto was not reliable, and sometimes failed, leaving the drive marked as Unmountable, which results in a prompt to format the drive, which obviously can be disastrous. The whole point of that instruction is to make sure that the file system for the drive is correct after the swap, because it will NOT be until you set it correctly. I'll try to see if there's a better way to word it. To illustrate what happens - Before swap: Drive R Disk 10 ReiserFS Drive X Disk 11 XFS After swap of assignments: Drive R Disk 11 XFS or Auto Drive X Disk 10 ReiserFS or Auto After FS correction: Drive R Disk 11 ReiserFS Drive X Disk 10 XFS

Shouldn't it be? It seems to me that it would be better for consistency if all formatting functions worked the same way, for interchangeability?

While I haven't seen the code involved, it would surprise me if both 190 and 194 were not checked, probably have been for a long time, as both have commonly been used by different manufacturers for quite awhile. I suspect this was another case of out of sync spin state (drive spun up but emhttp not informed). If unRAID doesn't know a drive has been spun up, it won't show a temp.

Nice, a Ryzen syslog! And it looks very impressive! You were able to boot at least, but I'm afraid you're running too close to the bleeding edge! This kernel is the first to have any support for Ryzen, but just guessing, it doesn't look like kvm (and related modules) have been updated for it yet. You have turned on ACS override, but I understand that's not working with Ryzen, not updated yet. For correct and stable operation, I think you'll have to wait for kernel and kvm subsystem updates. However there is one other user who seems to be fully operational. Look for the Ryzen thread (don't remember where it is). There are some very knowledgeable people there.

That's been a common problem here. We often have a very simplistic view of what reading and writing to a drive involves, and tend to immediately blame the drive if any errors occur. But there are many more components involved, all of which can cause issues, can fail. Drives and drive controllers are computers, have their own software, typically called firmware, that can crash, can be buggy, can need updates, can have power issues. Then there are the other components like cables (data and power), cable connectors, power splitters, ports (both on drives and on controllers), plus the actual software in the server, like the app involved, the file system software, the busses and their management, and the various drivers involved at higher and lower levels. That's why many of us don't recommend hot swapping, because only a percentage of what appears to be a drive failure actually *is* a drive failure. We would rather check the logs and SMART reports first, then proceed accordingly. I don't know what the percentage is, but it's my opinion that it's more often NOT the fault of the drive than it is. Just wildly guessing, maybe 30% of the time it's a true drive fault? We have seen many cases where a drive suddenly disappears, but after analysis determined the drive was perfect, and the controller crashed or malfunctioned, or a loose power or data cable slipped off, or there was a power issue, etc.

If you still get the "file is open" error, you will have to make sure the relevant app is not running. If you aren't sure what that is, you might try booting in Safe Mode, so that no plugins or other apps are started. If you still get it, you may have to disable even more, like Dockers and/or VM's.

A FAQ entry about Cache drive usage options

And here's another big vote for SageTV, except I have to confess I'm still running it on a Windows station, an older version too, so rather useless for advice here. I've been depending on it since January 2005, somewhat of a digital hoarder myself. I was excited by the open sourcing of SageTV, but haven't kept up with it in awhile. Need to.

I'm rather sure there's a script out there that does what you want, no personal experience with it. Try the User Scripts plugin, and check the Additional Scripts thread (has scripts for the User Scripts plugin. That may be where I've seen it. The User Scripts plugin can schedule scripts for periodic operation.

I split this off because it's not directly related to IPv6 inclusion, although I understand why you started it there. But it's certainly worthy of more discussion. I'm not sure if this is the right forum for this discussion. You brought it up in relation to what types of features are appropriate for different target audiences, and where should LimeTech be putting their emphasis. It can be moved if desired. (as you can see, I'm not a very good wordsmith!) I have to start though by saying this is a very small company, not currently able to spend the millions that might be needed for mass market appeal and support. For a long time, it was just Tom, and during those days I'd say the target was technologically advanced hobbyists, those with higher media storage needs, and generally able to use the command prompt, at least follow instructions there. Since then, it has been gathering a much wider following, from gamers and less technical home users to small companies and higher end techies. Personally, any attempt to woo low tech users just scares me. If we suddenly gained a large number of them, the amount of support they would need is way beyond what we could do. I already feel swamped at times. I'm of course just speaking for myself, not for Lime Tech. Slightly off-topic, I was rather shocked by your statement that SNAP was one of the first things you found, and shortly after that you found other long deprecated tools. We've tried hard to put the right info out there, but there seems to be no way to intercept everyone's preferred way of locating info. For example, we constantly see users asking for support with no syslog or diagnostics, even though we post about it every place possible we can think of! Obviously, we need to be all ears for additional ideas. But we're just users, unpaid volunteers, unable to keep up with all of the needs. And the company is just not big enough, or well-funded enough, to meet all needs. I think they have done a terrific job so far, with what they have. I'm curious how you found SNAP? While old stuff isn't actively hidden, it's buried rather deep!

I split the discussion of target demographics by @Dissones4U off to its own thread: The unRAID target demographic (from "Requesting IPV6 in unRAID kernel") It's a worthy topic for discussion, but not directly relevant to IPv6 inclusion.

I don't think you want New Config again, if you have already used it and then assigned all of your drives. All you need to do is make sure that "Parity is already valid" checkbox is checked, then start the array. I would always do a parity check afterward though, to check everything. It sounds like you have already done this, but if not: You would use New Config to start a completely new array configuration, making sure you select the Retain option to save nothing, as you don't want any of the previous config assignments saved. Once you return to the Main page, you would have an empty array, which you can then assign all of the drives, including the Parity disk.

That's only a later piece of the syslog, not useful, too late. What we always need to see is the very first error that occurs. What we also always want is not just the syslog, but the full diagnostics, containing all syslog pieces (including the first) plus a lot of other info about the server. Please see Need help? Read me first!, and attach the diagnostics zip. Typically, without seeing anything else, it's likely a USB port is flaky, dropping connections at random times, which causes the loss of full unRAID operation, no way to access its own configuration. Often, it's a matter of trying other USB ports, sometimes avoiding any USB 3.0 ports.

No settings needed, it's already up there, on the second line between Forums and Online Users.

And you can add a parity drive or 2 any time you like, just assign it and let it build.

I'm glad it's working, but I don't think you'll be happy. I think ALL of those will negatively impact performance, some dramatically! You should not need ANY of those on a modern functional motherboard. Try removing some of those, testing different combinations, and find the combo with the fewest that still works, hopefully there's only one that's absolutely needed. Computers now-a-days really depend on all of those features to run at full speed. I'd have to say this seems to indicate a bad BIOS or bad motherboard (or perhaps a bad PCI card of some sort).