Sandwich

This card has a "JMicron JMB5xx chip"; should it work well? I was told in another thread that it's best not to use "port multipliers"...?

"Port multipliers"? Is that the same as SATA expansion cards? I got this off Amazon: https://www.amazon.com/dp/B083WF95Q1?psc=1&ref=ppx_yo2_dt_b_product_details My MB only has like 6 SATA ports natively, so I need extra ports somehow... Ahh, awesome, thanks!

I've been emptying out my largest data drive (6Tb), moving its contents over to other data drives, in preparation for making it a second parity disk. In unBalance, there were two top-level directories listed on the drive: /Public and /system. The /system/docker/docker.img file was the only file under /system that I could see. I moved both directories to other drives, letting unBalance decide which drives to use. It seemed to go fine, and in Settings -> Docker, the drive-agnostic path should still be the same: /mnt/user/system/docker/docker.img Nevertheless, Docker hasn't been able to successfully start since the move. Any ideas? Diagnostics attached. cube-diagnostics-20210926-2115.zip

My plugins page takes 2 minutes to load. The Notifications page is set (by default, apparently) to Never Check for updates. Any ideas?

Hmm... I do have a 1Tb SSD I could add. Would it make sense to do something like partitioning part of it (half?) to be a cache drive, and leave the other part for holding appdata or whatever? Ooh, so if I'm messing around with the PMS docker container, just stopping PMS isn't enough; I should halt the entire docker service?

Awesome, that looks like it'll do the trick, thanks so much ChatNoir and SimonF. That leaves two questions - the one about transferring the four 3Tb drives all at once or one at a time, and the one about if moving data around drives will disrupt PMS... EDIT: Specifically, I'm thinking more of Plex's internal cache & data files, not of the audio and video media files that it manages.

Ahhh, thanks! So I shouldn't be doing any data relocation from the terminal then?

This. ^^^ I'm a professional web developer, and I know for a fact that no matter the site, forcing a minimum width is unnecessary. Let things flow and scale, my dudes. I often open the unRAID interface on one of my side monitors, which are pivoted 24", so effectively 1200x1920. I have to zoom out to 90% in the browser to get the full width of the interface to show. :-/

Nobody?

I have about 5.75Tb of data that I'm trying to transfer from my Drobo to an unRAID box. I've rsync'ed all the data over to the unRAID box as it's currently set up (see below), and am running a parity check: Current setup: unRAID 8Tb (Parity) 6Tb (Data; with 5.25Tb of the data) 2Tb (Data; with 0.5Tb of the data) Drobo 4 × 3Tb (5.75 of data with single-drive redundancy) My understanding is that once the parity check is complete, my data will be safe on unRAID from a single-drive failure. Then, my goal is to transition to the following: Desired setup: unRAID 8Tb (Parity) 6Tb (Parity) 4 × 3Tb (Data) 2Tb (Data) Drobo (retired) Of particular note is that the 6Tb drive will need to transition from being a data drive to being a parity drive. To that end, I'll need to move the data from it to the other data drives (the 3Tb drives coming from the Drobo). But what's the best way to go about doing this? Do I pull the drives out of the Drobo and put them into the unRAID box one at a time, rebuilding parity each time, or add them in all at once? And particularly, once they've been added, how do I move the data from the 6Tb to be spread out among the 3Tb drives? Finally, much of this data is related to my Plex Media Server (PMS) and Winamp libraries. I'd like to get those up and running with the data in unRAID (PMS in a Docker and Winamp on my PC) before I pass the point of no return in removing drives from the Drobo. Winamp I'm not too worried about, but if I get PMS set up while the data is on the 6Tb and 2Tb drives, will I have to update things once the data gets moved to the 3Tb drives? Like, if PMS is set up in a Docker, where are those PMS/Docker files stored? Will that need to move too? Thanks for any help!

Will do. In the Main tab, the list of Array Devices has an Errors column. How much significance should one place on numbers there? Like, does that number include the typical situation of a sector marked as bad and reallocated elsewhere? To my understanding, that is a fairly common occurrence, and only really signifies a failing drive if it starts happening "en masse" (whatever that means).

Bit of an update and further puzzlement: I've gotten the 6Tb drive replaced, and the tech at the store assured me that the drive was error-free. Great! Same thing he said about the original 6Tb drive. 🙄 So I installed the replacement 6Tb and, unlike the original one, unRAID was able to format it. Yay! Then, since I need the largest drive in the array to be the parity disk, I `rsync`ed everything from the 8Tb (which had everything `rsync`ed from the Drobo5N) to the replacement 6Tb. That process took about half a day, and completed successfully. I then created a new drive config (Tools -> New Config), and assigned the 8Tb as a parity disk, and the 6Tb as data. It started to rebuild the parity on the 8Tb, which it said would take about a day. So I left it like that last night. This morning I come back to see that the process paused partway through, and there's an error notification on the screen: If I click on the disk log, the modal window just loads screen after screen of log rows, with errors scattered everywhere. At this point, I have no idea what to think. Full diagnostic attached. cube-diagnostics-20210318-0833.zip

Ok, that's actually good news (since it's both empty and under warranty); it means there was a reason the Drobo kicked it out, and a reason unRAID can't make use of it. Thank you all for your help, you've been great!!

No, from running the array in maintenance mode, clicking the disk, and running the check.

BTW, when I run a check on the 6Tb drive with `-n`, the result is this (canceled after a few minutes of whole-lotta-nothin): And the line with the dots just grows and grows.

Ok, so that does seem to have brought the 8Tb back, although I'm still scratching my head as to how it got borked in the first place. Nevertheless, thank you!! As for the original issue, the 6Tb drive... as best as you can tell, that does seem to be either a cable or drive issue, correct? And since I swapped out to new cables....

Geez, now I know where all that Holywood tech speak in movies comes from. O.O Phase 1 - find and verify superblock... - block cache size set to 703632 entries Phase 2 - using internal log - zero log... zero_log: head block 2058495 tail block 2058491 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:2058555) is ahead of log (1:2). Format log to cycle 4. XFS_REPAIR Summary Thu Mar 11 20:48:18 2021 Phase Start End Duration Phase 1: 03/11 20:45:54 03/11 20:45:54 Phase 2: 03/11 20:45:54 03/11 20:46:07 13 seconds Phase 3: 03/11 20:46:07 03/11 20:47:03 56 seconds Phase 4: 03/11 20:47:03 03/11 20:47:03 Phase 5: 03/11 20:47:03 03/11 20:47:03 Phase 6: 03/11 20:47:03 03/11 20:47:52 49 seconds Phase 7: 03/11 20:47:52 03/11 20:47:52 Total run time: 1 minute, 58 seconds done Great, so... now what? Do I stop the array from maintenance mode and restart normally? Currently, the Main screen still shows both disks as "Unmountable: No file system", although at least there's progress that the 8Tb's FS is "xfs" now instead of just "auto". ¯\_(ツ)_/¯ Also, if at any point in all this there's any indication whether the issue would be due to a failing drive vs failing MB vs random, please do let me know.

Phase 1 - find and verify superblock... - block cache size set to 703632 entries Phase 2 - using internal log - zero log... zero_log: head block 2058495 tail block 2058491 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 0 - agno = 3 - agno = 1 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Mar 11 20:28:53 2021 Phase Start End Duration Phase 1: 03/11 20:26:33 03/11 20:26:34 1 second Phase 2: 03/11 20:26:34 03/11 20:26:34 Phase 3: 03/11 20:26:34 03/11 20:27:46 1 minute, 12 seconds Phase 4: 03/11 20:27:46 03/11 20:27:46 Phase 5: Skipped Phase 6: 03/11 20:27:46 03/11 20:28:53 1 minute, 7 seconds Phase 7: 03/11 20:28:53 03/11 20:28:53 Total run time: 2 minutes, 20 seconds Does the above indicate it found issues that need to be repaired? The manual seemed to indicate there'd be a clearly stated option to use for re-running the check command, but I don't see anything that matches that description above.

It's not showing me the option to check filesystem status (presumably because the detected filesystem is "auto"). :-/

Odd... the filesystem of the 8Tb shows as "auto". EDIT: Ahh, but I do have a screenshot of that drive in unRaid 3 days ago, showing it as having `xfs`. I'll continue on that assumption.

Ah, of course, sorry! Here: cube-diagnostics-20210311-1945.zip

Ok, so tell me what to do.

Hmm. Ok, here's the extra wrench in the works: when the Drobo kicked out the 6Tb, I immediately bought an 8Tb "replacement" before realizing the 6Tb was still under warranty. Then, since the Drobo was down to single-disk redundancy, I ran the 8Tb through a week-long `badblocks` test (which it passed), and then installed it into my empty unRaid box. It mounted fine, I made it a share (or whatever the terminology is around creating shares on drives), and began another week-long process, that of using rsync to copy over all the data (just under 6Tb of data) from the Drobo to the 8Tb drive in unRaid. That completed successfully, and for a while (5-10 days?), unRaid was working super-fast (relative to the slowpoke Drobo) on the network with just the 8Tb drive. Then, just in the last few days trying to figure out the issue with the 6Tb drive, suddenly the 8Tb drive stopped being recognized by unRaid as well. Same exact reported issue: "Unmountable: No file system". Does any of that shed any more light on what might be going on here? Is it possible that, instead of the drive being bad, the motherboard/controller is bad? But if so, why would it copy 6Tb of data over without a hitch? But if the drives are bad, why has every test under the sun except attempting to mount them in unRaid saying the drives are fine? 🤔

I've swapped SATA cables with new ones out of the bag; no immediate change. I then stopped the array to try formatting the drive again. After about 2-3 minutes it just stopped formatting, still reporting "Unmountable: No file system", with a notification on the side: The disk log is attached below, as is the full diagnostics as requested. Thank you so much for your time and assistance with this! 6tb new cables formatting stopped errors.txt cube-diagnostics-20210311-1824.zip

Trying to set up an unRaid box to replace my Drobo 5N (which, thankfully, still works after 5+ years). I've got a Gigabyte GA-Z97MX-Gaming 5 motherboard (not sure what SATA controller it has as the specs page doesn't seem to say). I have a WD Red 6Tb drive which was in the Drobo for 2.5 years and recently (supposedly) crashed; the Drobo ejected it from the array for some reason. I took it in for warranty replacement, where they did a thorough test that took a couple of days and reported the access time for each and every sector of the disk. It apparently passed with flying colors, so not sure why it was ejected from the Drobo. In any case, I gave it a complete, full NTFS reformat in my Windows PC and ran `chkdsk /R`, both of which completed with no errors or issues. At this point I'm very confused as to why it was ejected from the Drobo. So I plug it into my otherwise-empty unRaid box to see what happens. As expected, it reported that the NTFS-formatted disk was unmountable, so I clicked to have unRaid format it. Now it says the "FS" column is "xfs", but reports that the disk is "Unmountable: No file system". I have no idea what's going on. Finally, the disk log shows a lot of errors, but I don't know what's going on with those either. I'm attaching both the SMART report and the copied disk log (is there a better way to extract that log than just copy-paste?). Any ideas? Thanks so much for any help you can give me. 6tb disk log.txt cube-smart-20210311-1119.zip