Seagate 8TB Shingled Drives in UnRAID


Recommended Posts

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.:D

 

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)?

Link to comment
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.

 

2.png

Edited by Benson
Link to comment
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 :o

 

ss.png

Link to comment
  • 3 weeks later...

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
  • Upvote 2
Link to comment
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?

Link to comment

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

 

 

Link to comment
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.

Link to comment
  • 1 month later...
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 by themaxxz
Link to comment
  • 3 weeks later...

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.

Link to comment

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.

Link to comment

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?

Link to comment
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.

Link to comment

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?

Link to comment

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?

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.