RobJ

The reason I asked for diagnostics was there were so many things wrong with the file system structures, that I was afraid that either he had tried to repair the drive instead of the partition (sde instead of sde1 or md4), or it wasn't an XFS drive, but a drive with a similar file system, enough to find file system pieces and try to construct an XFS file system. I'm afraid the damage is so severe that it's too much for the current xfs_repair, and it's crashing. I really hope you have a backup for the data. I'm a bit intrigued by your statement of a 19 day old parity copy, but didn't understand what you mean by that. Is that a *separate* disk that you can put back in? And was Disk 4 fine at that time? What exactly do you have from 19 days ago?

unRAID is an all RAM based OS, built from scratch each time it boots, so the unRAID boot flash drive provides both the copies of the distro to be expanded into RAM, plus the 'persistent storage' for all configuration and logging, in /boot/config and /boot/logs. Other user scripts and programs are generally also stored on the flash, although could be on a Cache or array drive if not needed until after array start. Probably best to move it back to the flash drive: mv /dskt /boot Then to run it, you would either run: /boot/dskt ... Or: cd /boot dskt ...

Sorry, I didn't see that 68 or the "in the past". Good catch, Brian. 194 can be taken literally, 190 is "one hundred minus", so the 076 means it's currently 24C, the 045 means a max of 55C, and the 032 means it once reached 68C, well over 55C. I would Preclear it 3 times at least, and see if it holds up. If it does, then it survived the over-temp. I'd still monitor it for awhile.

Please see Need help? Read me first!, and attach the diagnostics zip.

Looks fine. If the 'Power on hours' of 1458 can be trusted (is it a refurb?), it's a young drive in good condition.

I'll start by giving some background on the current wiki method, and then touch on a few things you may not have thought about. I had noticed already several users using unBALANCE, and had been thinking about adding a method based on it, but I won't be able to completely flesh out the steps as I've never used unBALANCE, and can't because I don't use User Shares (which of course partly explains my own methodology). I've always preferred knowing and controlling exactly where everything is, and I've a personal catalog file I keep open in an editor tab with all of my series and categories listed, with the drives they're on. For example, I know that my Alias shows are on Disk 1, and all my PBS stuff is on Disk 4. User Shares are convenient for many, but for me it just adds another layer to the access. Off-topic though ... But converting drives is a drive issue, only indirectly a User Share issue. It's drives that are formatted, and that dominates the problem. I don't know for sure, but I suspect if you wrote out the steps for doing the entire array with unBALANCE, it would be close to 19, or maybe even more. A general method for users at large has to handle every contingency and every situational variation, as safely as possible for the least technical of users. That always takes longer, and often more steps are involved, 'just in case'. It inevitably means lots more words! I do think my method is the most straightforward, safest, and fastest though, but then disk shares is what I work with and understand. It does have an extra step or two to accommodate User Shares. For User Share users, which is most or almost all unRAID users, unBALANCE sounds attractive, and I agree that it's a great plugin! It uses basically the same rsync command, so should have the same speed and file verification checksumming for the individual transfers. But in operation over multiple drives, it's likely to take longer, because it's moving the files off one drive to the others, then moving the files back when you do the next drive, and possibly moving some files multiple times, pushing them around the various drives to keep them out of the way of the next format operation. With my method, files only move once. The only way to make sure no files get moved more than once with unBALANCE is to carefully manage exactly where each file starts and where it ends up, and that sounds like something you wanted to avoid, if you don't want to care where the files are. To me, my method seems just as seamless, and allows full operation just as much. Both ways, you have to stop the array, make changes, then restart the array, just as many times. When I did it with 6.1, I didn't have to use New Config, just adjust the assignments and restart the array. Unfortunately in 6.2, something changed and it won't allow that, so we had to add the New Config step, which I agree does add a little extra hassle. 6.0 and 6.1 users don't have to do that. We have requested that to be corrected, so we can just restart the array, but as far as I know, it hasn't happened yet (haven't checked it recently though). The strong cautions though are just as important, for either method! How do you know for sure that there were not files lost when you did it? Because if there were any other processes (internal plugins, Dockers, scheduled scripts, or VM's, or externally scheduled backups) writing files to the array, they could very well have added files to the very drive you were emptying with unBALANCE. In fact, the emptying of a shared drive makes it the most attractive target for writing new files to. Either you make absolutely sure that nothing else could be writing to the array, or you should run unBALANCE a final time, just to make sure that nothing is left on the drive (written to it after unBALANCE had swept across it), before you format it. Does unBALANCE after moving folders come back and check if they have reappeared on that drive, with more files in them? So I'll add a general unBALANCE-based method, and I think many users may prefer it, as it does hide some of the detail, but it will take longer to perform. And they will have to manually configure unBALANCE for each drive emptying. The steps will have to have just as many warnings. Users who aren't running anything else at all will obviously have a simpler time, can ignore the warnings, but that's a special case. I really don't want any of this to be daunting or nerve-wracking, but each time we hear of a user doing something we hadn't thought of and getting into trouble, the word count increases. The more words, the more daunting it appears ... (just look at this post for instance!)

To fully understand what's happening, we would need to see both diagnostics, one where it's seen and one where it's not seen. Then we can see what the kernel is seeing (or not seeing). You will also want to make sure it's seen by the BIOS at bootup.

Added to Guides and Videos!

In this case, the yellow is a false positive, nothing wrong, although it's a little odd. Some devices need a kick to initialize them, a hard reset to start them up. You won't see any speed degradation with only one drive attached.

Please see Why do I see csrf errors in my syslog?

You are very welcome! (I often forget to say that, not very good at the social niceties!)

No, you can run without parity fine. You've obviously learned the most important lesson, the importance of backups! What parity gives you is additional fault tolerance for this particular copy of your data. If a drive fails, you replace it and using parity rebuild it exactly as it was. That adds convenience when the next drive fails, and of course they all do sooner or later. But so long as you have good and up to date backups, you can live without the convenience of parity assisted recovery. And of course, without a parity drive you don't need a cache drive. There are other uses for it, but that's of much less importance.

5.01 is the Memtest86 that comes with the unRAID distro. I don't think it would make much difference running the Windows flavor. Just to clarify, both Memtests are based on the same code, and neither are Linux or Windows programs, probably pure assembly based (maybe something added for the PassMark GUI). If either one detects errors, you can trust there are problems. The PassMark one is more advanced, supports the latest memory tech, and is probably the one you should use. For more detail on both, including their history and differences, see my (unfinished) FAQ entry: How do I test my RAM? The general rule is that if you can see any errors at all, there's a bad RAM stick, don't use it. But I think it's possible to see RAM errors if it's configured wrong, wrong timings or wrong voltages. Not an expert opinion though ... Edit: Hah! I see ufopinball just beat me!

There's nothing important that changed, so yes you can just live with it. You clearly changed something in the BIOS, because its memory layout changed, and several other small things changed too, like the CPU being slightly faster, but not enough to be detectable! Two changes did NOT happen that we wanted, but may not be important. The 2 phantom ports are still there, and in IDE emulation mode, but who cares as you can't use them anyway. The Parity2 drive still appears to have a loose connection on boot, with exactly the same errors as last time, so nothing you did changed that. The only other possibility is a power draw issue to the drive - you can check that by spinning all the drives down, waiting a few seconds, then spinning them all up at the same time (the Spin Up button), and checking the syslog for the same error messages. If none, guess you'll have to live with it. As to the BIOS betas, all new software and all upgrades of any software are beta until they have been tested on your own machine. If there aren't adverse reports about them, and you have used your motherboard tools to backup your current BIOS, then it should be safe to try one of them.

Please please, just post the diagnostics.zip file! If there's something you don't want included, use the anonymization options, or remove it from the zip.

You can roll back to 6.2.4, from the LimeTech download page, just replace the bz* files and reboot. However, users are reporting the the Docker support in 6.3 is not backward compatible with 6.2, so you will have to redo the Docker setup. I imagine you won't have to redo the Dockers themselves, just the main docker config and docker.img. It will be interesting to see if an earlier kernel works better for you.

Just a quick look at the diagnostics, but nothing stood out as a problem. The one thing I can recommend is to check for an upgrade of your motherboard BIOS (from 2013), sometimes helps.

Post a syslog after you install it, and I'll compare the 2 for changes. I'm a little hesitant to agree. A dead unconnected cable should not be visible.

You can close it and keep the operation running by using screen, part of the Nerdpack. A helpful guide to using screen is Screen Tips.

Commands like that aren't made to be typed by hand! I recommend using PuTTY, which does support copy and paste, although in an awkward way. If nothing else, you can copy the command into a file, copy the file to the boot drive, then run the file from a terminal session. Well yes they do, some using the Unassigned Devices plugin to add and control extra drives. But a true backup should always be on a different machine, so most use other means for backups, like a second server, or cloud backups, etc.

OK, that could explain it. But that indicates poor device management in the BIOS, which should KNOW those ports aren't there, aren't available. That's more impetus for finding a newer BIOS. By the way, you said you saw 6 SATA ports. The syslog however indicates the 6th one may not be working. The kernel designated it as a DUMMY, which generally means there's a port there, but the BIOS says it's not operational (which is what it *should* have said about those other 2 ports!). More reason for an updated BIOS!

Recently, there have been a few questions posted and topics started, application related, but put into the old Applications board of the Legacy section. Topics there are very old, from long ago versions of unRAID. Yet the questions do seem appropriate for a general Applications board, and are generally cross platform, not specific to Dockers or plugins or VM's, and may involve combinations of those app platforms. Here's an example: DLNA Upnp with Squeezebox LMS not working. I could not think where best to move this. I'm wondering if we should re-activate this old board, or better, create a new Applications board in the Applications Support section? A general Apps board would be more consistent with our move to the idea that apps are apps, whatever the platform. But we don't really want to create more boards... If nothing else, we should lock the old Applications board, move it to the Deprecated section.

As to the ACPI issues, I don't see anything very unusual, but since your motherboard BIOS is from 2013, I'd recommend checking for a newer one, *might* help. The second parity drive appears to have a loose connection, might check all of its connectors, both ends of any connected cables, power and data. The kernel thinks it sees something on the last 2 SATA ports, but gives up trying to identify them. You have IDE emulation turned on for your onboard SATA drives. When you next boot, go into the BIOS settings and look for the SATA mode, and change it to a native SATA mode, preferably AHCI if available, anything but IDE emulation mode. It should be slightly faster, and a little safer, if you do connect anything to them. Once those last 2 ports are using the native SATA AHCI option, then we should be able to see what's there, if anything.

In this case, it's not really a matter of how long it has, but that it's *already* useless as a parity drive, so you might as well remove it now. I don't see any indicators of mechanical issues, so if this drive had had files and folders, you would probably have had plenty of time to copy them off. But it doesn't! Parity drives don't have a single bit of data on them so there's nothing to save! What it does have is lots of bad sectors, obvious media surface damage, at such a young age, and therefore the drive cannot be trusted. I'd pull it now, and run without parity until you get a replacement for it. I can't think of any advantage to keep using it, and it's slowing down all writes, for nothing. What danioj said is exactly correct.

The drive looks fine, should be good. The only thing that concerns me is the Raw_Read_Error_Rate, which dipped down to 64, but is now back to 83. Might want to monitor that.