jcarmi04

I am having issues in which the (unassigned devices) drive that my camera's write to borks. It reads as 0 available across the board and is not available as a share. I can Unmount it, cycle Shinobi, then after a few minutes remount and it works - or can reboot the server. To test, I have left Shinobi off and the drive on and have not had any issues. Thoughts? I can't quite tell if this is a MariaDB issue, Shinobi, or ? log.txt

Quick update, fwiw: Stopped parity check, rebooted, and now sitting at 2.7% in 45 minutes. My speed is a steady 80 MB/sec, but compared to a few recent entries things still seem askew. DateDurationSpeedStatusErrors 2020-11-22, 18:54:0513 hr, 9 min, 52 secUnavailableCanceled0 2020-10-17, 04:57:3412 hr, 29 min, 52 sec177.8 MB/sOK0 2020-10-14, 19:17:4621 hr, 40 min, 3 sec102.6 MB/sOK5 2020-10-13, 13:43:2613 secUnavailableCanceled0 2020-10-09, 19:39:249 hr, 34 min, 13 sec232.2 MB/sOK0 2020-10-09, 07:11:3621 hr, 19 min, 25 sec104.2 MB/sOK0 2020-09-21, 13:46:392 hr, 24 min, 35 secUnavailableCanceled0 2020-09-21, 03:32:2521 hr, 5 min, 15 sec105.4 MB/sOK0 2020-09-19, 10:20:304 hr, 7 min, 23 sec539.1 MB/sOK0 2020-09-13, 12:20:4321 hr, 3 min, 42 sec105.5 MB/sOK0 2020-09-05, 10:18:1921 hr, 4 min, 4 sec105.5 MB/sOK0

Currently sitting at a manual Parity Check completion of 1.2% after a (mere) 10 hours and 52 minutes. A few days ago I noticed my transfers from my server were slow. I have since tested: -Slow transfers from server -Slow transfers to server -Slow transfers within server Some transfers start off well (hundreds of MB/sec) before screeching to 1-2 MB/sec. Reads seem okay. Writes are where I am thinking things are getting clogged at. Was hoping a parity check may clean things up, but short of rebooting (which I have not done) I'm not quite sure where to head with this one. Attaching logs and will take any help. Thanks!!! tower118-diagnostics-20201122-1628.zip

Also, all, fwiw, the last disks I added were before I upgraded from unRAID 5.x to 6.x. Given my recent rfs issues I'm glad to see xfs is the default for new disks.

Hi all (@bjp999 @Frank1940 @garycase @johnnie.black @RobJ others): I'm FINALLY calling this RESOLVED. Thanks for all of the help, especially coming through with what I think the fix is, @bjp999! With half of my unRAID disks converted from rfs to xfs and lots of tests run it appears I'm finally in good shape with stalled/failed transfers. After dealing with this for the better part of a full calendar year, I've certainly made my rounds (multiple times) replacing router/switch, CAT cables, SATA cables, NICs, a M/B, HDDs, using multiple Windows and Linux comptuers to test, changing SMB copy settings, so many network and local (unRAID) copy tests and trials, among other things. Hope my string can serve to assist with anyone in the future, especially as a way to rule out a Windows copy error: 0x8007003b. RFS for unRAID in 2017 = BAD. @Frank1940, thanks for staying with me recently. I'll be digging more into my SMART reports and probably adding a second Parity. Will @ tag you as I venture forward as post-worthy things come up.

@Frank1940 thanks for posting. In the process of doing a RFS to XFS conversion in the background to see if this finally licks my issue(s). Regarding the SMART reports, I did a quick scan and didn't notice anything too alarming...but would obviously lean on you/others for recommendations as to what might get me prepared for failures. (Most of the 196+ rows are "Old Age" and not reporting anything crazy and I've posted my row 5 values below that "may" look a bit wonky.) Wrt 6 drives for 25 TB vs 13 for 24 TB, I WISH...and eventually will. Just been using unRAID since approx 2010 and purchased what was available then. Hence, having wayyyyyy too many 1 TB HDDs kicking around my place without a purpose Here are my higher WORST/THRESHOLD ratios. With the exception of disk4 (Toshiba 5 TB), all others are WD drives...so those values may be "normal"!? disk3 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0 disk4 5 Reallocated sector count 0x0033 100 100 050 Pre-fail Always Never 0 disk5 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0 disk8 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0 disk9 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0 disk11 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0 disk13 5 Reallocated sector count 0x0033 200 200 140 Pre-fail Always Never 0

Thanks @bjp999! If it makes sense, I can update to the latest version of unRAID. I don't want to bite off too much...but don't think there'd be a downside to doing this. (I wouldn't have to rebuild Parity, if I'm remembering correctly, right?!)

@jonathanm I was reading that when converting from rfs to xfs it was potentially finicky; is this at all accurate (@bjp999)? Would happily choose the easiest option, at this point...

@bjp999 I kinda figured you'd recommend that, so been locating the drives. Both had previously been unRAID disks, so I'll plan add both the 2 and 3 TB drives to the array and format XFS. Should I copy files between both XFS disks to test this out or just unload the 5 TB to these (and then format the 5 TB as XFS)? Any other thoughts or recommendations? I'm thinking I'd run into rsync issues if trying to go from a 5 TB to a 2+3...so might have to manually copy stuff...!?

@bjp999 4.86 TB I'm pretty full up: 1: 1.88 of 2 TB 2: 2.95 of 3 TB 3: 1.49 of 2 TB 4: 4.86 of 5 TB 5: 1.17 of 2 TB 6: 1.90 of 2 TB 7: 2.97 of 3 TB 8: 1.34 of 2 TB 9: 2.94 of 3TB 10: 2.68 of 3 TB 11: 1.64 of 2 TB I haven't been able to move stuff around for a long time to free things up better ...

Thanks @Frank1940 ! Will be reading up on it today...

@bjp999 Thanks...catch you later. Happy Father's Day!

@bjp999 I do have some slow access times (seems like the server is getting choked...but no reason it should), but I think my main faults result in writes. Since all of my disks are, in fact, over half full should I proceed as follows for testing: 1. Add new RFS-formatted drive to the array (I think I have a 1, 2, and 3T available I could use for testing) 2. Copy files to the drive and watch performance 3. Add new XFS-formatted drive to the array (will have to purchase a 5T) 4. Copy files to the drive and watch performance I'm trying to understand the relevance of a RFS over half full and whether to include steps 1 and 2 or to exclude. Also, I can format a 1, 2, or 3T as XFS and replace any steps above or include (new steps 3 and 4, bumping the others to 5 and 6). *My largest drive is a 5T Parity and Disk 4 is also 5T.

@bjp999 I haven't noticed predictable or consistent problems (either single disk share or multi-disk share), but can run through a few tests to rule in/out things if you think.

@bjp999 v6.1.9. Thanks, rfs for all disks except cache which is btrfs. I actually preclear all disks on a separate box, so it unfortunately won't factor in.

@bjp999 I'm assuming RFS as I've precleared all drives with @Joe L. old preclear utility. How can I check? I reckon that's gonna be a BEAR to redo all drives....

@Frank1940 It is a Share that includes Disks 1, 5, 8, 10, and 11 and hosts my movies for Plex, Kodi. Allocation: High-water Min free: 0 Split: Auto split any dir as req Inc: See above Ex: None Cache: No

I just double checked and all copies I did today were from User, not Disk. (In the past I may have done differently, but have not in a while.) Any thoughts, tests, etc I can try?

Just figured I'd round it out with: 7. MC "d1" to the original multi-disk share: SUCCESS UGH!

Well, I have no idea what's going on... I just created a couple single disk shares (d1 is to the M/B (Disk 1), d9 and d10 are to the SuperMicro card (Disks 9 and 10)). 1. Win10 multi-disk share (Disks 1, 5, 8 (M/B), 10 and 11 (SM)) to "d1": SUCCESS 2. Win10 "d1" to "d9": FAIL 3. Win10 "d1" to "d10": SUCCESS 4. MC "d1" to "d9": SUCCESS 5. Win10 "d1" to "d9: SUCCESS 6. Win10 "d1" to the original multi-disk share: FAIL The speeds aren't fast, but right now I'm going for operational. Log attached and server details below. 2x 5T (Toshiba Parity and disk) 2x 2T (Hitachi) 2x 3T (Seagate) 4x 2T (WD) 1x 3T (Toshiba) 1x 3T (WD) 1x 250G (Crucial Cache) 1x 4G (JD FireFly Flash) 1x ASRock Z87 Extreme M/B 1x Intel I5-4570 @ 3.2GHz CPU 4x 8G Kingston RAM 1x Cosair 650w PSU 2x AMD Radeon HD Video Cards (VMs) 1x SuperMicro AOC-USAS2-L8i (8 port) unRAID Server Pro v6.1.9 HVM: Enabled IOMMU: Enabled Docker: Installed Docker Containers: -BTSync (gfjardim/btsync:latest) (Config using Cache and data stored to a Share) -Plex (limetech/plex:latest) (Config using Cache and data accessed via Shares) VMs: -1x Win7 (Using Cache only) -1x Win10 (Using Cache only) tower118-diagnostics-20170617-0643.zip

Thanks for the crack @Frank1940 however I've definitely made those rounds...and, unfortunately, I've timed out before when copying from disk to disk via mc (so thinking something solely server related).

@limetech @garycase @johnnie.black @Rajahal @jonp anyone...Help Please! I replaced the 3 TB that I thought would resolve this, per the above and I'm producing the same copying error. For giggles I tried connecting from a Win 7 instead of 10 (nope), directly from a PC to the server (nope), and switched out the SATA port of the controller card from that disk (nope). While unRAID is an AMAZING solution and serving my real desire for it (reliable backup solution), my unRAID server is essentially unusable now.

Update: First, thanks, @garycase for the suggestions! 1. Today I ran a New Config and brought a drive back one at a time, copying a handful of 3-5GB .mkv files to each. I ended up failing with the same Windows error on my 9th (of 11) and only that drive. I'm currently running a Parity-Sync and will try to replace the drive and see what results it yields, but so far a VERY positive lead. 2. A couple less important, but still interesting notes: 2.a. My copies, to whichever drive/drive combos/shares, would typically fail and produce the previously-reported Windows error (or a Linux fail, via mc) when copying 3+ GB .mkv or .iso files. I didn't have quite the same failure rate with .jpgs, though it was still present. Additionally, yesterday I copied a 100 GB file and - while transfer speeds ranged from 10-100 MB/sec (hovering mostly closer to 10 MB/sec) - the file did not fail once. I thought that was slightly interesting and perhaps may coincide with my next bullet. 2.b. When copying .mkv files, for instance, I noticed I zip through around 100 MB/sec for most of the file, but my file transfer stalls and bottoms down to 0 MB/sec at the beginning and end of pretty much each file. Thoughts? Regardless, thanks @garycase/all...more to follow...

At this point, I may just have to try that. Thanks for staying on this with me, garycase!

Unfortunately, some of the drives that fail to copy are directly connected to the Mobo. I can try to power down and unplug the controller card if there may be value in ruling that in/out.