extrobe

Thanks, I’ll check that option out! yes, it’s really so I can repurpose one of the slots (or maybe 2 by also using the onboard Sata) - I recently moved things around to add a gpu, so things are a little cramped now with one of the hba cards pretty much rubbing against the gpu which can’t be good for either, especially as these cards get pretty toasty!

I'm looking to upgrade a couple of my 8-port controllers (Dell H200's) with 16 port controllers, to free up some PCIe slots. 9201-16i's seem to be the recommendation - but from Australia the only place I can find to buy them from is China/HK - but I've seen advice to avoid these as they can be knock-offs. Does anyone have any recent experience with a seller in CN/HK they can share? (Or know another place to look for from AU?)

Yes, just changing slots. I'm trying to get it to read off the original disk (the disk itself should have still been physically ok, it was just approaching EoL), but struggling to get it to include it in the pool. Working my way through some of the BTRFS troubleshooting steps, but starting to look like a lost cause EDIT: Looks like it's the other Crucial disk which is not showing up - but there was nothing to suggest it was an issue before hand - in fact, I checked the SMART data before I started the replacement as wanted to see how much life that one had left. When I try to mount it, it says the Special Device doesn't exist - any diagnostics I can do on this to work out why that might be / confirm it's damaged? Looks like the data on the original disk has also already gone - when I try to mount it, it says wrong FS type

I did swap 2 of the disks around (the 2x Samsungs) - that was because I thought the 'unmountable filesystem' message was specific to that disk, so swapped the bays over to check it wasn't a connection issue. But I checked the assignments still matched before moving on.

demeter-diagnostics-20200906-1810.zip Diagnostics attached. I did follow that link for no spare port, but it went back to the single-disk procedure, and wasn't sure if that was the right one to follow - so figured that as the multi-disk procedure was to just select a new disk (seemingly like for a standard disk) I thought I could just hot-swap them instead 😕 Edit: References to disk Crucial_CT500MX200 = Old Cache 4, Crucial_CT500MX500 = New Cache 4

Ok... I did the following... Stopped Array Started Array in Maintenance Mode Ran mkdir /x mount -o degraded,usebackuproot,ro /dev/sdh1 /x Realised I should probably run that not in maintenance mode Stopped Array Started Array (normal) and the cache pool seemingly is back online Not sure if I've lost data or not, but I can't get docker to start "Docker Service failed to start" EDIT: Did a restart, and back to being unmountable EDIT: Repeating the previous steps, this time copying to the array using Midnight Commander - but getting a lot of copy errors (keeps saying [stalled]), and pretty sure there are some missing some directories. Would putting the old disk in again, and using the above command be a sensible next step? EDIT: Adding the old disk back just gives the warning 'all data will be overwritten when you start the array', so doesn't feel like this will work

Although, perhaps I'm just being a dunce - is the Unmountable message just reflecting that the pool as an entirety can't be mounted? It's prompting me to format the 'lead' disk in the cache - it was cache 4 which I swapped out

I have a 4xSSD Cache Pool on BTRFS (3x480GB, 1x500GB) Few days ago, one of the drives was being flagged for replacement (500gb). New one arrived, and read through the FAQ post The only bit I was different on, was I didn't have a spare port, so instead did the following... - Stopped the array - Pulled out the faulty disk caddy - Replaced the disk with the new one - Selected the new disk in the pool (which is pretty much the same process I use on the main disks) But... whilst the offending disk shows as a 'new device', now one of the other other 3 disks is showing as Unmountable: No File System I've tried stopping the array again, and removing/re-inserting the disk. I've also tried putting the old disk back in, but I don't seem to be able progress from here. Is this recoverable? I have partial backups, so not all is lost, but annoyingly I think my PLEX instances were on my exclude list, and probably my biggest 'loss'

I'd love to see partial-parity scheduling. eg, do 25% each week, meaning a full scan is done every 4 weeks. Currently, doing a full scan takes nearly 25hours, so don't tend to run them unless I have had a dirty restart or something. Being able to phase it would allow users to keep parity in check

Bummer - that does make it more challenging Perhaps I'll add that to my rainy-day to do list!

It's taken quite some time, but have finally finished applying disk encryption to all 20 drives using the 'shuffle' method. But I'm not sure what the best approach would be to encrypt the cache drive(s). I have a 4-disk cache disk configuration (4x 500gb) in btrfs. I know one of these disks needs replacing soon anyway, so will I be able to ... - Remove one of the disks from the cache array - Install the new disk - Format with encryption - Add to cache array - repeat for each subsequent disk or is there a better approach?

Thanks BRiT - thought it was worth asking. I'm replacing both anyway, and I'll later stick one of the SMR drives back into the array - see what happens!

Over the last few weeks, I've 'lost' one of my parity drives on 3 occasions (not always the same drive). I get a 'Parity1 Disabled' error. On each occasion I ran extended SMART reports, and couldn't find any issues. I've swapped out power, data cables etc, but never found the cause and on each occasion I ended up re-formatting and re-adding the parity drive. The 2 parity drives are connected to different controller cards (I have 3xH200's), and different power outputs from the PSU. I do have 2 new WD 'Red' drives onorder to replace both parity drives which are currently Seagate Archive drives (ST8000AS0002, which I understand are SMR drives?). But it's bugging me why the parity drives keep getting kicked out. It then occurred to me that on all 3 occasions I had been running Unbalanced to shift data between disks as I go through applying XFS Encryption to each of the 18 array disks. Could the combination of shifting data between disks, and the less-than-ideal SMR drives being used for Parity have something to do with this? Or is it simply the fact that the law of probability means I'm more likely to encounter such an issue during this type of activity?

Thanks @jude, this did the trick for me in 6.7 stable as well

Right, I think I know what I did now - Because I planned to remove both disk 16, and disk 1 eventually, I removed disk 1 from the 'included' disks for each share, but also from the Global Share Settings - this seems to be what triggered the data on disk one to be treated differently. In theory, fixing it was just re-adding disk 1, but was made tricker by half my dockers hanging because the data in the shares they referenced was not there, and had to force a hard reset. Gah.

I'm currently in the process of decommissioning one of my disks, by following the Shrink Array process. Disk 16 is to be removed. All data shifted via Unbalanced, formatted, and now running the clear script. All is good. But I think saw Radaar going nuts telling me everything was missing. And indeed, when I go into my shares, I'm missing a heck of a lot of files - not looking good! I then realised that under shares, disk1 is listed as a disk share - and when I go to the root folder of my server, there's disk1 folder share sat along side the other shares. Now, I did remove disk1 from the disks to be used for all shares, as I plan to decommission that one at some point too - this might have something to do with it. Any idea what's going on, and the cleanest way to sort it out? Can I just use Krusader or something to rehome them directly to an appropriate disk?

I asked pretty much the same question on reddit the other day. One of the devs responded that they're working on a change to allow you to force a 'move' when you're mapping a remote path - for this specific reason

Yes, that's certainly a possibility. I think I'm going to order another anyway (they're not super expensive) and then do some more testing Now, I did have all three of these cards in consecutive slots - and the one I'm having problems with is the one sandwiched in the middle. These things can get pretty hot, so that could be a contributing factor as well.

I get the same error - 6.7 is the next major release (with a new dashboard etc) that's currently being tested.

After applying the latest update and rebooting, UR reported 4 disks being missing. All were attached to the same breakout cable on the same controller. (3x DELL Perc H200s) Usual trouble shooting - shut down, check connections - restart. 8 disks now missing - arghh, but it's all disks on that same controller. By now I'm looking on eBay to see how quickly I can get a replacement, but tried moving the controller to a different slot - and boom - all worked fine. -- How likely is it that this was in fact a MoBo slot issue, and how likely is it that this is a sign I need to replace the raid card?

I also migrated to sickchill - very simple. I'd previously rolled back to v2018.10.06-1-01 Then backup --> create sickchill docker --> restore Done Thanks for the heads up on SR

Hi - having a bit of trouble with the extended test. It's been 'running' for best part of 3 days now, but don't think it's actually doing anything. On the plugin tab, it says it's processing a specific share ( Status: Processing /mnt/user/wAppDataBackup) , but it's been like that for most of the time it has been running. There's no disk activity, so don't think it's actually doing anything But unsure how to check / force stop / if this is actually normal or not

Yes - I have 20 bays in total - and I've had the disk in several of those bays, which covers different sata connections to the PSU, and different raid controllers. I think it's must have been some sort of corrupted filesystem, but that corruption appeared to be being replicated whenever the disk was rebuilt - and about half way through actually shifting the data to different disks, it 'gave up'. I way eventually able to mount the drive in my Ubunutu VM and recover about 200GB - reckon there was closer to 1TB of data, so unless I can figure out how to recover it from parity ,looks like I've lost it. The important stuff is backed up, so will just be media. Just got to figure out how to get out of this 'loop' I seem to be in. Edit: There's a huge Lost & Found folder, so looks like I'll be able to recover most data. So just need to work out how to sort out the unmountable drive. Think I have a plan though - fresh drive, re-build the drive - then remove it out of the array and rebuild parity without it. re-format the disk, add it again - then copy files across from the repaired drive.

Getting a bit lost with this now! I tried re-formatting and re-building, but same errors I tried a repair - same errors So tried re-formatting again, but converting to something other than xfs before converting back to xfs - same errors Figured it might be a disk issue, so bought a brand new disk. Re built it. Same darn errors. So began a unbalanced session to move everything on it to other disks. About half way through, the disk became unmountable. Restarted - still unmountable, although the disk and array shows as 'active' (not emulated), but can't get access to anything. So stopped the array, took the disk out the array and restarted the array. Disk is now emulated, but the emulated disk is also not mountable. Not really sure where I should be taking this next - I do have a spare drive (well, the original one which turns out to be fine, as ran extended tests overnight on my windows PC) - but suspect it'll just rebuild this corrupt data. At the point unbalanced was running, the data itself all seemed fine - I was randomly picking various media files stored on the disk, and everything was playing fine - but now don't appear to have a way to access / rebuild any of that data - I have 2x parity, but if it's emulating a corrupt unmountable drive, I"m not sure if that counts for anything. The disk is question I've currently got sat on my desk. Might try firing up a linux VM on windows to see if I can pull anything from it

Ran the checker - and got a lot of warnings, such as and the message No idea what most of this means, but doesn't sound good. Having read up on others having similar issues, it doesn't sound like an xfs_repair is the way to go, so I'll remove the disk from the array, start the array (and let parity take over), re-format the disk and add it again as a blank disk