trurl Posted April 4, 2017 Share Posted April 4, 2017 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)? Quote Link to comment
JorgeB Posted April 4, 2017 Share Posted April 4, 2017 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. Quote Link to comment
Vr2Io Posted April 4, 2017 Share Posted April 4, 2017 (edited) 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, 2017 by Benson Quote Link to comment
JorgeB Posted April 5, 2017 Share Posted April 5, 2017 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 Quote Link to comment
SSD Posted April 5, 2017 Share Posted April 5, 2017 2 hours ago, johnnie.black said: Love it! A glimpse into the future. Quote Link to comment
BRiT Posted April 26, 2017 Share Posted April 26, 2017 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 2 Quote Link to comment
SSD Posted April 27, 2017 Share Posted April 27, 2017 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? Quote Link to comment
BRiT Posted April 27, 2017 Share Posted April 27, 2017 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 Quote Link to comment
JorgeB Posted April 27, 2017 Share Posted April 27, 2017 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. Quote Link to comment
themaxxz Posted June 11, 2017 Share Posted June 11, 2017 (edited) 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, 2017 by themaxxz Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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. Quote Link to comment
SSD Posted June 30, 2017 Share Posted June 30, 2017 Is parity an archive disk too? Are you copying just one stream at a time, or multiple streams? Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 Parity is a WD Red, one stream at a time (rsync script) Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 (edited) 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, 2017 by tucansam Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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. Quote Link to comment
HellDiverUK Posted June 30, 2017 Share Posted June 30, 2017 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. Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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? Quote Link to comment
HellDiverUK Posted June 30, 2017 Share Posted June 30, 2017 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. Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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? Quote Link to comment
JorgeB Posted June 30, 2017 Share Posted June 30, 2017 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. Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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 Quote Link to comment
JorgeB Posted June 30, 2017 Share Posted June 30, 2017 17 minutes ago, tucansam said: few dozen KB for jpgs and other files (nfo etc) from Plex Those I expect can get pretty slow. Quote Link to comment
tucansam Posted June 30, 2017 Share Posted June 30, 2017 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? Quote Link to comment
HellDiverUK Posted June 30, 2017 Share Posted June 30, 2017 I usually wait until the access sounds stop. When the drives are clearing the cache, you can hear them seeking. Head thrashing, really. Quote Link to comment
JorgeB Posted June 30, 2017 Share Posted June 30, 2017 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) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.