Seagate’s first shingled hard drives now shipping: 8TB for just $260

[WeeboTech]

Your are welcome

... The storage review results were skewed by having the rebuild occur on an 'active' live server. ...

Do you think the big slowdown they observed is not related to SMR "write penalty"?

 

on a live active server in RAID1 mode, Yes, I think the storage review article proved that they would suffer in a multi user random access mode.

 

For unRAID, with general sequentiual streaming and/or sequential 'moving' I think they will do fine.

 

They wouldn't do as well in my bittorrent server or my central file server, but for my backup server and/or movie server they will do fine.  It's a usage case scenario.

 

I have no doubt these SMR drives are quite useable as unRAID data disks... not so sure about parity yet. I'm trying to follow garycase logic... I've put together small bash script which does multiple copies of a given file, reporting performance, but it uses Linux "cp", so it not just writes, it reads-writes-reads-writes... and this will change the writing performance results. I'm searching for a method to read a file completely in memory, in a bash script, but did not find any so far... will have to do it in C, probably.

 

I wouldn't go too crazy, if you have a spare SSD, fill it with your test bed.

Or you could make a tmpfs of a reasonable size and seed it with a test file then write that file to multiple filenames at once. (in bash)

There is also dd if=/dev/zero of=/mnt/disk#/test### type of testing you can do.

 

With the DD you can have it write a 50GB file multiple times in parellel to prove/disprove the full band write on sequential files.

 

Here's my write/read test script, you will have to edit it as you see fit for size and/or dropping cache and/or reading after write.

Perhaps taking out the initial sync to avoid skewing things when spawning a few in parallel via screen or tty's.

root@unRAIDb:/boot# cat local/bin/writeread4gb 

#!/bin/bash

if [ -z "$1" ] 
   then echo "Usage: $0 outputfilename"
        exit
fi

if [ -f "$1" ]
   then echo "removing: $1"
        rm -vf $1
        sync
fi

bs=1024
count=10000000
count=4000000

trap "rm -vf $1" HUP INT QUIT TERM EXIT

total=$(( $bs * $count))

echo "writing $total bytes to: $1"
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero bs=$bs count=$count of=$1 &
BGPID=$!

sleep 5
while ps --no-heading -fp $BGPID >/dev/null 
do kill -USR1 $BGPID
   sleep 5
done

echo "write complete, syncing"
sync
echo 3 > /proc/sys/vm/drop_caches
exit
echo "reading from: $1"
dd if=$1 bs=$bs count=$count of=/dev/null
echo "removing: $1"
rm -vf $1

[pkn]

Interesting review of the drive.

 

STORAGE REVIEW OF SEAGATE 8TB SMR

...

 

"The HGST He8 HDDs completed its rebuild in 19 hours and 46 minutes. The Seagate Archive HDDs completed their rebuild in 57 hours and 13 minutes."

 

Well, I've just done Seagate Archive rebuild myself, twice, both times it took slightly over 15 hours.  Maybe the Synology NAS does it thru the arse  backwards  upside down very, very differently from unRAID.

[pkn]

... There is also dd if=/dev/zero of=/mnt/disk#/test### type of testing you can do. ...

Ah! Thanks! Looks like /dev/zero is exactly what I was searching for.

[garycase]

I think what we're all trying to come up with is a test that will force the Archive drives to operate outside of the mitigation strategy Seagate has designed into the drives.    But they've done such a nice job of this that's it's tricky to do that.

 

You have to be sure the files you're writing aren't large enough to trigger the "it's a whole band so we can skip the band rewrite" logic;  be sure a bunch of files together aren't sequential so they do the same thing;  and ensure there's enough of these random write activities to fill the persistent cache.  Once the persistent cache is filled, the writes will slow down dramatically and performance will be abysmal.

 

The good news is that what you're testing has shown so far is that this simply isn't likely in typical UnRAID use cases.    If you use your server to do a LOT of small random writes that's a different story => I know WeeboTech has a lot of bit torrent activity, and also has a LOT of MP3's ... doing a lot of writes with these would likely kill the performance on an archive-drive based setup (especially if it was the parity drive) ... but for most users who use their servers are media servers they'll never encounter the write slowdowns.    And of course anyone who never writes more than 25GB at once won't have the issue.

 

[SSD]

There is evidence from the storage review that random writes are not cached to the persistent cache.

[danioj]

@pkn: my supplier has informed me that the 3 8TB's I have ordered will arrive tomorrow!  ;D

Conratulations! 

Can you post or PM me the procedure you followed for recording your test timings. Ill do the same thing just to provide extra data.

Here you go. Some steps are optional or not applicable, and, as always, there is more than one way to skin a cat, but what I did is here.

 

WARNING! Do not do this with disks containing needed data!

-- You have been warned.

 

1. Disable auto page refresh: Main==>Settings==>Display Settings==>Auto page refresh==>Disable

    Automatic page refresh is nice, but slows server down considerably.

2. New config: Main==>Tools==>New config

    This resets array configuration - it forgets all disks.

3. Assign disks - Parity, and  two data

    unRAID will say "Start will bring array online and start parity sync".

4. Check the "Parity is already valid" checkbox.

    To be able to skip parity sync and still fool unRAID that it has valid parity, since we are only interested in writing speed test.

5. Start array.

    This will start parity sync.

6. Cancel parity sync.

7. Stop the array.

8. Unassign (set to "no device") one data disk.

9. Start array.

    It will say "unprotected, replace the missing disk a.s.a.p."

10. Stop array.

11. Assign back the disk which was unassigned in step 8.

12. Start array.

    This will start data disk rebuild.

 

Then I just copy-pasted the main page progress report into a separate file from time to time.

 

Thanks for the info! Shame, I wont be able to run the tests this weekend like I expected. Just had a call from the supplier and now they are saying mid-April. Grrrrr.

 

Have my C2550D4I, memory, SFX PSU and Silverstone case already waiting to put these in too! Now I have to wait!

 

Ill run the tests when I get them though.

 

Sigh.

[pkn]

I think what we're all trying to come up with is a test that will force the Archive drives to operate outside of the mitigation strategy Seagate has designed into the drives.    But they've done such a nice job of this that's it's tricky to do that.

Isn't it an interesting challenge - to develop a strategy which can defeat another strategy? 

 

You have to be sure the files you're writing aren't large enough to trigger the "it's a whole band so we can skip the band rewrite" logic;

This is fairly easy to achieve

and ensure there's enough of these random write activities to fill the persistent cache. 

This too

  be sure a bunch of files together aren't sequential so they do the same thing; 

But this condition of being "not sequential"... In old FAT days I would say that to make file writes "not sequential" I would have to:

1. Empty the drive completely

2. Fill the empty drive with (numbered) files of size N x 1.5

3. Delete every, say, 3rd or 4th of these files

4. Only then start to write files of size N

I'm not sure even this would work with modern sophisticated filesystems...

 

Or, the testing script would have to work on sectors level, not on files level.

[c3]

Or, the testing script would have to work on sectors level, not on files level.

 

Not sure accessing sectors would be beneficial as real workload is going to be via a filesystem with it's own approach to disk layout. As you have already seen, that is LBA based, and the drive-managed SMR drive, effectively hides LBA actions via caches.

 

This is one of the reasons f2fs exists. A potential parallel in SMR would allow for host-managed or hybrid SMR drives to deliver better capacity and performance.

[garycase]

Agree it's far more complex with modern drives => and as c3 noted, if you're using the OS's file system, that also provides another layer of abstraction.

 

I suppose we should basically just be glad that the mitigations on the drives work so well => but clearly it would be nice to know just what sequences might be likely to "hit the wall" of write performance with these drives.

 

[BRiT]

Agree it's far more complex with modern drives => and as c3 noted, if you're using the OS's file system, that also provides another layer of abstraction.

 

I suppose we should basically just be glad that the mitigations on the drives work so well => but clearly it would be nice to know just what sequences might be likely to "hit the wall" of write performance with these drives.

 

A guess, but I suppose this situation might hit the worst case scenario.

 

SMR Parity Drive

Multiple Data drives filled to different percentage Ievels (nonSMR)

Simultaneous writes to the data drives of small files.

 

Thats the rare situation that I reason might/could boil down to random write patterns on the SMR Drive. The tough part is not knowing if writes at completely different locations can still be cached on the nonSMR cache band. Of course that is just an educated guess as I dont have money to burn on testing hardware that the device manufacturer won't release the real specifications for.

 

I debated posting this as I know several closed minded individuals only want to see absolute facts posted and dont care for open discussions.

 

[danioj]

Some more tests conducted which seem to show how the drives perform.

 

http://www.reddit.com/r/DataHoarder/comments/2vxboz/seagate_archive_hdd_v2_8tb_st8000as0002_write/

 

Liked the last post:

 

dennisbirkholz 1 point 21 days ago*

My benchmark with dd if=/dev/zero of=/dev/sdX bs=4k is like:

  5GB: 179 MB/s

10GB: 144 MB/s

20GB: 138 MB/s

30GB: 133 MB/s

40GB:  70 MB/s

50GB:  54 MB/s

60GB:  47 MB/s

70GB:  42 MB/s

250GB:  30 MB/s

It will eventually settle at about 27 MB/s, but that does not matter any more.

For me the disks are OK and work, I am now using ZFS on debian jessie with ZFS raidz1 (=RAID5), so I have no initialization phase and so the speed is sufficient even at 30 MB/s. But it is not the 150MB/s or whatever speed announced in the data sheet for large writes but it is totally OK for data sinks like a daily backup.

 

 

Rysvald 1 point 21 days ago

Yes, that table was pretty much exactly what I was looking for.

I think the proper way to market the disk would be: Continous read: 190 MB/s Continous write: 27/150* MB/s * Using internal XX GB pre-archive zone/cache/whatever.

permalinkparent

[garycase]

A guess, but I suppose this situation might hit the worst case scenario.

 

SMR Parity Drive

Multiple Data drives filled to different percentage Ievels (nonSMR)

Simultaneous writes to the data drives of small files.

 

Thats the rare situation that I reason might/could boil down to random write patterns on the SMR Drive. The tough part is not knowing if writes at completely different locations can still be cached on the nonSMR cache band.

 

I suspect that would indeed eventually cause the system to "hit the wall" of write performance, although it's likely it would take a LOT of writes to get there, as I'd certainly think that the writes would be cached in the persistent cache on the parity drive.    Scattering the writes to different data drives (as you've suggested) may just put enough time between writes on the parity drive that even if the small files were sequential on the data drives, the parity drive may still cache them instead of recognizing that collectively they were full band writes.

 

I suspect that's in fact why the rebuild times were so much longer in the StorageReview RAID-5 rebuild than on an UnRAID system => the data in a RAID-5 is striped, so the disk activity to do the rebuild has a different pattern than on UnRAID, and the writes likely weren't always recognized as full bands.

 

The simple fact that it's so challenging to force serious write degradation is a good sign vis-à-vis the performance of these drives in an UnRAID array.    The major downside of using them is you need to be aware of the potential, and willing to accept the abysmal performance that might occur from time to time.    Overall I'm very impressed at how well Seagate has mitigated the write issues of the shingled technology.

 

 

[garycase]

Liked the last post:

 

"...  I think the proper way to market the disk would be: Continous read: 190 MB/s Continous write: 27/150* MB/s * Using internal XX GB pre-archive zone/cache/whatever.

 

This would definitely be a more accurate way to market the drive -- but it's VERY unlikely Seagate (or any other maker) is going to outright SAY that their drives could degrade to such abysmal performance levels (which are even worse than 27MB/s according to the Storage Review tests).    I think they consider themselves well covered by making it clear these are "Archive" disks and not designed for significant IOPS loads.    And indeed, the mitigations in the drive make them work very well in that role.

 

[pras1011]

Heres another test:

 

mdcmd set md_write_method 1

 

This makes all drives spin up and become part of the write. Its speeds up the writing speed.

 

Can someone try this?

[pkn]

Heres another test:

 

mdcmd set md_write_method 1

 

This makes all drives spin up and become part of the write. Its speeds up the writing speed.

 

Can someone try this?

 

Googled, tried to read the "Enable reconstruct-write mode" topic, did not understand half of it (sorry, it's Sunday morning which came after Saturday night).

 

Tried this command anyway. I was copying large amount of files, Midnight Commander's progress was reporting ~38 MB/s. I aborted copying, issued this magical command, resumed copying - now MC reports ~70 MB/s. 

 

BTW, how do I set it back to default? I mean, besides rebooting?

[pras1011]

mdcmd set md_write_method 0

 

This will put it back to normal.

 

I use to write huge bluray mkv files.

 

And thanks for trying it.

 

I can't explain the command maybe someone else can?

[pkn]

mdcmd set md_write_method 0

 

This will put it back to normal.

 

...

Got it, thanks.

 

Just to report the setup: server Testt, unRAID Trial 6.0-beta14b, H8DME-2, 1xOpteron, 4GB DDR2, parity 4x2TB RAID-0 pool via Areca ARC-1110, two data drives 8TB Archive, XFS filesystems. Copying by Midnight Commander to data disk1 from NFS-mounted user share from server Front.

[pras1011]

These seagate drives look very promising but they are seagate and not known for their reliability!

[danioj]

Dear Daniel,

 

Thank you for placing an order with us, we now have the item(s) you ordered in stock ready for you to pickup.

 

*dances* 

[danioj]

Dear Daniel,

 

Thank you for placing an order with us, we now have the item(s) you ordered in stock ready for you to pickup.

 

*dances* 

 

Interesting packaging! (See IMG).

 

Going out tonight but couldn't help taking some pictures and plugging one of the drives in. Interesting initial thing though, I tried to do an initial S.M.A.R.T report before I do a 3 cycle preclear and it appears the drives don't come with S.M.A.R.T enabled (See Screen Shot).

 

 

For everyones benefit I intend to do the following before I go to bed tonight:

 

-- Enable S.M.A.R.T (and get an initial report) --

 

smartctl -s on /dev/sdc

smartctl -d ata -a /dev/sdc

smartctl -a -A /dev/sdc >/boot/20150402_SG8TB1_Initial_Report.txt

 

EDIT: Still some time so did some investigating. No need for the above. S.M.A.R.T was not enabled by default in my BIOS of my new board for the Backup Server. I don't know if enabling it forces some other command to be executed or not but no matter - enabled it in BIOS and was able to obtain an initial S.M.A.R.T report for 3 of 3 drives (EDIT - changed file to have all 3 reports included in one file - attached).

 

-- Run 3 Cycle Preclear (bjp faster preclear is the one I am going to use) --

 

preclear_bjp.sh -f -A -c 3 /dev/sdc

preclear_bjp.sh -f -A -c 3 /dev/sdd

preclear_bjp.sh -f -A -c 3 /dev/sde

 

EDIT: Started preclear for ALL 3 drives in one go in a separate tty (God I love IPMI) using above command before I go out. Initial Pre Read running @ ~170MB/s for ALL 3 drives.

 

-- End--

 

Ill post the results of it once it is done.

20150402_SG8TB123_Initial_Report.txt

[garycase]

Glad you finally got the drives.    It'll be interesting to see how long Brian's version of pre-clear takes for these.

 

[danioj]

Glad you finally got the drives.    It'll be interesting to see how long Brian's version of pre-clear takes for these.

 

Hope it doesn't skew the results, but I VPN'd in and set the other 2 going at the same time in separate tty's. I don't think it will based on first glance as all 3 Pre Reads are running at the same speed. Did an edit of the above post to reflect.

[garycase]

Running 3 at once is fine -- the only time it would be an issue is if they were running on a controller that was bandwidth limited (e.g. a 4-port controller on a PCIe x1 slot).

 

[switchman]

As part of your testing, are you going to set one of these up as a parity drive?  It would be nice to know how it behaves.

[pkn]

As part of your testing, are you going to set one of these up as a parity drive?  It would be nice to know how it behaves.

Here.