April 4, 20179 yr 2 hours ago, tucansam said: I always preclear my disks outside the array in another machine, but the one time I did take a drive straight from its antistatic bag and placed it in my array, I believe it did a preclear before adding it to the array. It was years ago, but if I recall correctly, the array was down for something like 30 hours total, with me banging my head against the wall the entire time (I was new to unraid at the time). Perhaps that's the clear he's talking about? I prefer to keep the terminology clearer. When you add a disk to the array, unRAID clears it if it is not already clear. You can also preclear a disk, which makes it clear before (pre) adding it. I haven't done either recently. So, which of these end up in the parity log, clear, or preclear, or both (or neither)?
April 4, 20179 yr 5 minutes ago, trurl said: I haven't done either recently. So, which of these end up in the parity log, clear, or preclear, or both (or neither)? Clear only.
April 4, 20179 yr 12 hours ago, danioj said: OK - sorry all, I completely screwed that post up. Please let me assure you, it was all coming from a good place. I didn't realise that clears were recorded in the parity check log as well. NB: I think I will be asking LT for a change to the logging to indicate what it was that was actually run. But Ill get to that later .... So based on my log and the timeline of events (before I edit the post again and get it wrong) my log is this .... 2017-04-03, 16:22:17 19 hr, 48 min, 40 sec 112.2 MB/s OK 0 2017-04-02, 19:13:52 22 hr, 54 min, 43 sec 97.0 MB/s OK 0 2017-04-01, 21:00:28 20 hr, 30 min, 27 sec 108.4 MB/s OK 0 2017-03-30, 09:57:57 14 hr, 59 min, 16 sec 148.3 MB/s OK 0 2017-03-29, 18:35:46 21 hr, 3 min, 48 sec 105.5 MB/s OK 0 2017-03-01, 20:02:50 19 hr, 32 min, 49 sec 113.7 MB/s OK 0 I am confused if Clears are logged as well why there are not more entries. I did the following (working from the bottom up): - Added new 8TB parity disk (no clear was required just a sync) - I assume that was entry 2 - Replaced 3TB data disk with another 8TB disk (required a clear) - Disk rebuild 3TB disk => 8TB disk - Parity Check ran in that time - I assume that was entry 4 - Replaced 3TB disk with another 8TB disk (required another clear) - Disk rebuild 3TB disk => 8TB disk Given that list of events I am finding it difficult to see what that 148.3MB/s is? If it was a clear then surely I would have a similar one as I added a second 8TB disk that required a clear. I am confused. I just thinking those abnormal result and try to reproduce. I belive those relate some calculation bug, but not sure only happen in 6.3.3 or not. ( BTW this may not be same as OP case ) Say short in long, I force unRAID belive the array ( with 6TB parity ) was clean, then I make a 3TB disk disable and add again, so it will perform sync on that 3TB disk. In fact, the max speed just ~110/MB/s ..... after complete, the result will be like that. The calculation wrongly count by 6TB instead of 3TB. Edited April 4, 20179 yr by Benson
April 5, 20179 yr 9 hours ago, Benson said: Say short in long, I force unRAID belive the array ( with 6TB parity ) was clean, then I make a 3TB disk disable and add again, so it will perform sync on that 3TB disk. In fact, the max speed just ~110/MB/s ..... after complete, the result will be like that. The calculation wrongly count by 6TB instead of 3TB. Yes, that's an old bug, not related to the case above, but it does provide some interesting results
April 26, 20179 yr So I added 3 of these Seagate Archive 8TB drives into my 4TB HGST 7200rpm array. I'm seeing good speeds for my Parity Checks regardless of the mixed drive situation. The check is now around 18.5 hours. Very acceptable to me for the additional 20TB of storage I gained. Parity SYNC (Creation) when setting a 8TB drive as Parity: 2017-04-24, 13:54:17 17 hr, 28 min, 9 sec 127.2 MB/s OK CLEARING the old 4TB Parity Drive to use as a data drive: 2017-04-25, 02:44:04 8 hr, 18 min, 30 sec 267.5 MB/s OK Parity CHECK with 3x 8TB Archive and 5x 4TB HGST: 2017-04-26, 12:35:31 18 hr, 31 min, 55 sec 119.9 MB/s OK Parity CHECK with 5x 4TB HGST: 2017-04-01, 11:43:17 8 hr, 43 min, 16 sec 127.4 MB/s OK 2017-03-01, 11:43:43 8 hr, 43 min, 42 sec 127.3 MB/s OK 2017-02-01, 11:43:17 8 hr, 43 min, 16 sec 127.4 MB/s OK 2017-01-01, 11:45:26 8 hr, 45 min, 25 sec 126.9 MB/s OK 2016-12-01, 11:45:24 8 hr, 45 min, 23 sec 126.9 MB/s OK 2016-11-06, 20:48:31 8 hr, 44 min, 33 sec 127.1 MB/s OK 2016-11-01, 11:42:29 8 hr, 42 min, 28 sec 127.6 MB/s OK
April 27, 20179 yr 3 hours ago, BRiT said: So I added 3 of these Seagate Archive 8TB drives into my 4TB HGST 7200rpm array. I'm seeing good speeds for my Parity Checks regardless of the mixed drive situation. The check is now around 18.5 hours. Very acceptable to me for the additional 20TB of storage I gained. Parity SYNC (Creation) when setting a 8TB drive as Parity: 2017-04-24, 13:54:17 17 hr, 28 min, 9 sec 127.2 MB/s OK CLEARING the old 4TB Parity Drive to use as a data drive: 2017-04-25, 02:44:04 8 hr, 18 min, 30 sec 267.5 MB/s OK Parity CHECK with 3x 8TB Archive and 5x 4TB HGST: 2017-04-26, 12:35:31 18 hr, 31 min, 55 sec 119.9 MB/s OK Parity CHECK with 5x 4TB HGST: 2017-04-01, 11:43:17 8 hr, 43 min, 16 sec 127.4 MB/s OK 2017-03-01, 11:43:43 8 hr, 43 min, 42 sec 127.3 MB/s OK 2017-02-01, 11:43:17 8 hr, 43 min, 16 sec 127.4 MB/s OK 2017-01-01, 11:45:26 8 hr, 45 min, 25 sec 126.9 MB/s OK 2016-12-01, 11:45:24 8 hr, 45 min, 23 sec 126.9 MB/s OK 2016-11-06, 20:48:31 8 hr, 44 min, 33 sec 127.1 MB/s OK 2016-11-01, 11:42:29 8 hr, 42 min, 28 sec 127.6 MB/s OK Clearing of the 4T drive seems too fast. Is that right?
April 27, 20179 yr There's no way that time can be correct, but it's what unRaid is reporting. I think it's a bug in the UI. I think it used 8TB as the size instead of 4TB, thus producing the 2 Fast 2 Furious speeds. The time delta is correct of 8 hours 18 minutes and 30 seconds. As best as I could find, here's the two event entries from the log files: Apr 24 18:25:34 X kernel: md: recovery thread: clear ... Apr 25 02:44:04 X kernel: md: recovery thread: completion status: 0
April 27, 20179 yr 5 hours ago, BRiT said: There's no way that time can be correct, but it's what unRaid is reporting. I think it's a bug in the UI. I think it used 8TB as the size instead of 4TB, thus producing the 2 Fast 2 Furious speeds. The time delta is correct of 8 hours 18 minutes and 30 seconds. As best as I could find, here's the two event entries from the log files: Apr 24 18:25:34 X kernel: md: recovery thread: clear ... Apr 25 02:44:04 X kernel: md: recovery thread: completion status: 0 It's an old bug, speed is reported according to parity size, so when the cleared (or rebuilt) disk is smaller speed is incorrect.
June 11, 20179 yr On 2017-3-8 at 2:52 AM, garycase said: ... Note that it would likely be a bit longer in a mixed array with a bunch of 4TB drives and an 8TB archive parity unit (and perhaps a few 8TB data drives). My parity check times in a mixed 2TB, 3TB, 6TB and 8TB archive drives. 22 hr, 55 min, 33 sec 96,9 MB/s 22 hr, 13 min, 11 sec 100,0 MB/s 22 hr, 58 sec 101,0 MB/s Edited June 11, 20179 yr by themaxxz
June 30, 20179 yr Copying 20TB from one array of WD Reds to an array with mostly 8TB Seagate Archives, I get 40+MB/s for an hour or so, then 3.8MBs from then on until I cancel the copy, let the array sit, and start it back up. Shingle wall, I am assuming.
June 30, 20179 yr Is parity an archive disk too? Are you copying just one stream at a time, or multiple streams?
June 30, 20179 yr Aaaaaaaaaaaaahahahahahaa Right now I'm at 7.15k/s copy speed..... 1991 modem speeds! Docker completely shut down, there is literally nothing going on on the server or network except this file copy. And me posting this. Edited June 30, 20179 yr by tucansam
June 30, 20179 yr Update. I let the copy continue unmolested, and the 7.15k/s (sometimes as low as 4k/s) has corrected itself, I am back to 25-40MB/s depending. I imagine once the persistent cache fills again, I will be back to sneaker-net speeds. So the problem corrects itself, but it takes time. How does this work? The drive's cache fills and it eventually just empties it on its own, while continue to write, albeit slowly, from the copy operation? Now I know what to expect during very large copies and moves. Does anyone know if there is a GB limit that must be reached before the shingle wall is hit? Maybe I'll break up large transfers into smaller chunks, but it would be nice to know how small they have to be.
June 30, 20179 yr The Archive v1 drives have approx 20GB non-shingled cache. The v2 drives have a little more, something like 25GB. I use a v1 drive for parity, and at various times used them in my array, and had no issues with speed unless filling the drives initially. They're fine for unRAID and for something like Stablebit Drivepool on Windows, but they truly suck in RAID.
June 30, 20179 yr So after this initial data transfer they should be OK then? I've been running them for a while, slowly moving my 4TB disks to 8TB, maybe one a month or so. But this is the first giant transfer I've done. So I guess this is why I'm seeing it. Other than miserable slow downs that eventually recover, is there any danger to the drive?
June 30, 20179 yr 3 minutes ago, tucansam said: So after this initial data transfer they should be OK then? I've been running them for a while, slowly moving my 4TB disks to 8TB, maybe one a month or so. But this is the first giant transfer I've done. So I guess this is why I'm seeing it. Other than miserable slow downs that eventually recover, is there any danger to the drive? Unless you're regularly adding lots of data at once to your unRAID array, you shouldn't see any issues. I only put maybe 6-10GB on to my array a day normally, and sometimes 64GB in one lump (video from dashcam for later viewing), and I've not seen any slowdowns. I suppose the 20MB/s read from the SD card is slow enough that the Archive drives can cope OK. I've been using my Archive drives for well over a year now, either as parity drive in unRAID, as data drives in unRAID, or as data drives in a Drivepool on Windows. One has been used as a cold backup. I've had no issues yet.
June 30, 20179 yr Thank you for your help sir. One final question to anyone who may have the technical knowledge... How long should I wait between large transfers in order to allow the drive to "catch up?" IE, if I'm transferring several complete show folders via rsync, write a script to pause for 5 five minutes between each? 10? 30?
June 30, 20179 yr Are these small or large files? I have no speed issues copying TBs at a time to may server that uses 5 of theses disks, including parity, they are all large files though, 4GB and larger.
June 30, 20179 yr They vary. few dozen KB for jpgs and other files (nfo etc) from Plex, along with the media files themselves, everything from 500MB to 4GB and everything in between
June 30, 20179 yr 17 minutes ago, tucansam said: few dozen KB for jpgs and other files (nfo etc) from Plex Those I expect can get pretty slow.
June 30, 20179 yr Well, in every folder Plex has touched, there is a jpg, an nfo, and an sometimes other stuff. Plus the mkv, and jpgs for season posters. So if a show had five seasons and 15 episodes per season, that's 75 mkv files (usually 1.5-3GB), 75 jpgs (30-50k), 75 nfo files (2kb), plus maybe another five 30-50k season posters. So its not a whole lot of files, and the small ones transfer pretty much instantly. Plus the slow down has always, thus far, been on the large mkv files, not the small stuff. It will plug at 40MB/s for a long time, then drop to 20MB/s, then back up to 40MB/s for a while, then suddenly I'm down to 6MB/s, then 3, the under 1MB/s, then it will essentially stop (4k/s) for a long, long time. Long enough that I get up and do other things, and when I come back, its moved on and I'm back up to 40MB/s. Does this sound like the shingle wall behavior? Or should I be worried about something else?
June 30, 20179 yr I usually wait until the access sounds stop. When the drives are clearing the cache, you can hear them seeking. Head thrashing, really.
June 30, 20179 yr 8 minutes ago, tucansam said: Does this sound like the shingle wall behavior? Not really, I would expect that with mostly large files speed would be normal. I get always above 100MB/s (using turbo write)
Archived
This topic is now archived and is closed to further replies.