JonathanM

Do you have a folder named "cache" on any of your array disks?

No.

VNC doesn't support sound. https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software

As long as the power outage doesn't effect your internet connection to the server, then you can be notified.

Try removing both cache disks from the pool and starting the array, then stop the array and assign both disks at at the same time.

If something drastic was changed, it's easier to troubleshoot if you have to take affirmative action to update the script for the new executable than to have the script suddenly start failing because of a change in the file and you have no idea what happened. Imagine if for instance the behaviour of fusermount 3 required a new command line switch to make it work like fusermount 2 in certain circumstances. If your script didn't know it was working with the new fusermount, it wouldn't be able to detect the need for different parameters. I don't know if that's the case for this specific application, but in general it makes sense to have unique names for unique executables.

Before you get your containers all sorted, I'd recommend finishing the reiserfs to xfs migration that you seem to have started. You have plenty of free space, so now is the time to reorganize, before you start committing more data to the array.

Sounds like you taped pins 14 and 13, not 2 and 3. https://www.tomshardware.com/news/hdd-sata-power-disable-feature,36146.html

Hmm. Are you showing beta7?

References?

Licensing issues. https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

If you use the rsync commands documented in the sticky reiserfs to xfs conversion thread it will copy the folders intact with all the contents. If you use midnight commander, it's up to you to make sure the source and destination are correct, i.e. /mnt/disk1 on the left pane and /mnt/disk2 on the right. For the purposes of this exercise, NEVER operate in the /mnt/user tree. All commands and paths must reference /mnt/diskX and /mnt/diskY for source and destination. I personally recommend rsync vs. mc, for the simple reason that verification of a complete copy is easier to manage with rsync.

Do a force update. The latest version solved that issue for me.

Correcting check.

I could be wrong, but I don't think that will actually restrict anything except whether FCP will report it as an issue.

That's one sign of health. When you click on each drive in the main GUI it takes you to a page that lists smart attributes and allows you to run smart tests and view the results. In the ideal world you would want each drive to have recently passed a long smart test. However, those take several hours to complete, and don't need to be run regularly since unraid reads each sector during a parity check. Drive health is a complicated subject.

As long as parity is valid, there are no corrupted files. If a read operation gives an error, the rest of the array drives are accessed and the data that should be there is calculated from all the other array drives. That value is written to the drive to repair the read error. If that write operation fails, the disk is red balled, and is not used again. All subsequent reads and writes to that data slot are calculated and emulated using all the remaining array drives. "Moving" data off of that emulated drive slot involves reading and writing from all the array devices, so the least stressful way to keep that data safe is to rebuild it back to a new device. Since all sectors of all array drives are needed to emulate a missing device, all sectors must be put back on the rebuilt device to allow the new device to participate in the array parity calculation. If only the sectors containing active data were written, then parity would be wrong at the other sectors on the disk, and parity would need to be rebuilt. If a different drive were to fail, it could no longer be emulated accurately and data would be lost. The GUI is all that is needed to replace a drive, no need to go the shell. Removing a drive slot, even when all drives are perfectly healthy, is way more complicated. To remove a data slot you have to reverse what was done to add it. First, all data must be moved to other drives, then all the sectors of the drive to be removed must be set to 0 so the parity calculation is not effected when the drive is removed. That is a long process on a healthy array, on one that is having problems it may not even be feasible to do in a timely fashion.

Each user share has a setting which determines how it interacts with the cache pool. Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present. No prohibits new files and subdirectories from being written onto the Cache disk/pool. Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array. Only indicates that all new files and subdirectories must be writen to the Cache disk/pool. If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status. Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the array and onto Cache disk/pool.

Is it a correcting check? If so, run a non-correcting check and see if it's still there. If it's a non-correcting check, verify the health of all the array drives then run a correcting check. Follow up with a non-correcting check to see if it goes away. Don't run a correcting check with a known bad drive involved.

Ok, now that it's clear what happened, how can we keep it from happening to other users? It's happened before, and it seems to be an ongoing thing. What wording or changes with that warning could have prevented you from making that mistake?

It's probably in the FAQ, but more importantly it requires you to see the warning before it will allow you to format the disk.

Here's hoping the drive errors were actually a bad or loosened SATA cable and all your data is intact on the old drive.

Yes. Format is never a part of rebuild. The whole disk is rebuilt, with the existing format applied. If you apply a new format, it erases the old one. Doesn't mean the disk itself was bad, it could have been the cable or port. Not saying it wasn't the disk, just that a disk that is actually fine but can't talk to the host will show errors.

BTW, how do you know the disk actually failed, and it wasn't a communication issue?

As long as you don't format the slot, all data should be rebuilt. If at any point in the process you selected the checkbox and formatted, you erased the emulated and rebuilt data.