WEBVTT 00:00:00.400 --> 00:00:06.960 Seagate archive drives. These things are 00:00:03.840 --> 00:00:09.760 freaking cheap for how much capacity you 00:00:06.960 --> 00:00:14.240 get. I can actually link my drive cost calculator spreadsheet that I used to 00:00:12.160 --> 00:00:18.960 make this chart under the video, by the way. But when I started looking into 00:00:16.480 --> 00:00:25.199 picking up some of these drives for our long-term storage NAS, I heard the 00:00:22.320 --> 00:00:30.480 performance totally sucked. So, I asked Seagate to send a few of them over, and 00:00:27.359 --> 00:00:33.120 I went on a mission to figure out if 00:00:30.480 --> 00:00:39.200 there's a way to mask their performance penalty while still getting the cost 00:00:35.680 --> 00:00:42.559 benefit to build the cheapest 100 TBTE 00:00:39.200 --> 00:00:44.879 storage box possible. Well, my original 00:00:42.559 --> 00:00:48.879 concept ended up totally not working. That's a new one, right? But I learned a 00:00:47.280 --> 00:01:00.239 bunch of interesting stuff in the process, and here it is. 00:01:00.239 --> 00:01:07.680 Cooler Master's Mastercase Maker 5 features their free form modular system, 00:01:05.119 --> 00:01:12.000 allowing you to customize, adjust, and upgrade. Make it yours at the link in 00:01:09.920 --> 00:01:18.080 the video description. Now, before I can explain why archive 00:01:14.960 --> 00:01:21.280 drives are so cheap and at the same time 00:01:18.080 --> 00:01:23.520 why their performance is less than ideal 00:01:21.280 --> 00:01:28.320 for certain applications, we need a little bit of background. Without 00:01:25.439 --> 00:01:34.079 getting into too much grimy detail, data is stored on hard drives by arranging 00:01:30.560 --> 00:01:36.960 the polarity of the tiny magnets that 00:01:34.079 --> 00:01:41.119 cover the hard discshaped thing inside called a platter according to the 00:01:39.200 --> 00:01:46.880 instructions given by your operating system. A magnetized bit is interpreted 00:01:44.079 --> 00:01:52.320 as a one and a non-magnetized bit is interpreted as a zero. So you lay down a 00:01:49.920 --> 00:01:56.720 few billion ones and zeros in the right order, read them back, and boom, next 00:01:54.560 --> 00:02:02.399 thing you know, you're playing Crisis 3. Okay, then. So, traditionally, these 00:01:59.040 --> 00:02:05.520 little magnets were arranged laying flat 00:02:02.399 --> 00:02:08.319 in concentric circles on the platter. 00:02:05.520 --> 00:02:14.800 This is called longitudinal magnetic recording. It's easier. But eventually, 00:02:11.599 --> 00:02:17.360 hard drive manufacturers ran out of room 00:02:14.800 --> 00:02:22.239 and couldn't increase capacity anymore without making their platters so big 00:02:19.840 --> 00:02:26.640 that the latency penalty of moving the read and write heads around would be too 00:02:24.640 --> 00:02:31.200 high. Not to mention that I'm pretty sure that no one wants a 10 terbte disc 00:02:29.120 --> 00:02:36.640 in their laptop if it has to be the size of a vinyl freaking record. So the first 00:02:33.840 --> 00:02:42.239 solution then was perpendicular magnetic recording. standing those magnets up 00:02:39.840 --> 00:02:46.879 instead of laying them down. This required more complex read and write 00:02:44.400 --> 00:02:51.040 heads, the uh the record needle type ARM that moves around and makes that ticking 00:02:49.519 --> 00:02:58.000 noise whenever your drive is working hard, but has gotten us all the way to 00:02:54.640 --> 00:02:59.680 10 terabytes so far with maybe a little 00:02:58.000 --> 00:03:05.120 bit more headroom left before the magnets again just can't get any 00:03:02.400 --> 00:03:10.640 smaller, which is where shingled magnetic recording comes in. Now the 00:03:08.159 --> 00:03:16.239 read component of the head, remember the record needle thing, is narrower than 00:03:13.440 --> 00:03:22.000 the right component. So by layering the magnetic tracks half on top of each 00:03:19.200 --> 00:03:27.360 other, like the shingles on a roof, much more data can be stored without moving 00:03:24.480 --> 00:03:32.879 to more exotic materials to make the magnets smaller or even drastically 00:03:29.920 --> 00:03:38.159 redesigning the heads. Unfortunately, this means that while you can read at 00:03:35.440 --> 00:03:42.560 pretty much full speed, the 8 TBTE archive drives that we used for our test 00:03:40.159 --> 00:03:46.959 are rated at 190 megabytes per second reads, way more than enough for the 00:03:45.120 --> 00:03:52.239 gigabit networks that most home and small office users are running. Write 00:03:49.360 --> 00:03:58.400 speeds can be devastatingly slow, especially when they're random. You see, 00:03:55.120 --> 00:04:01.360 the right head is so wide that it would 00:03:58.400 --> 00:04:07.439 actually overwrite both the intended track and the next one over on the 00:04:04.560 --> 00:04:12.159 drive. So, it has to read the data that it's going to accidentally overwrite. 00:04:09.920 --> 00:04:16.639 store that somewhere else, either in a solid state cache or in a reserved part 00:04:14.560 --> 00:04:21.440 of the disk platter somewhere else, organize it, and then finally 00:04:19.040 --> 00:04:26.000 sequentially write back both the data it's supposed to be writing in the first 00:04:22.960 --> 00:04:28.560 place and that data it had to shuffle. 00:04:26.000 --> 00:04:35.680 This is called a read modify write and it can be slow as all hell. So, let's 00:04:32.240 --> 00:04:38.320 talk then about my idea. I wanted to use 00:04:35.680 --> 00:04:45.360 the reasonable read speeds, the low cost, and the 247 operation ratings of 00:04:41.840 --> 00:04:48.479 archive drives in one of my lime unrade 00:04:45.360 --> 00:04:51.280 systems. I wanted to combine that with 00:04:48.479 --> 00:04:56.160 the reliability and all-around high performance of enterprise capacity 00:04:53.520 --> 00:05:01.520 drives to get the best of both worlds. So the way unrade works is that your 00:04:58.639 --> 00:05:05.120 data is actually written directly to the individual discs in the array which is 00:05:03.840 --> 00:05:09.600 great because in the event of a catastrophic failure let's say you lose 00:05:07.039 --> 00:05:14.080 two drives simultaneously at least anything written to the rest of the 00:05:10.960 --> 00:05:17.199 drives is still there and an additional 00:05:14.080 --> 00:05:20.320 drive or two drives acts as a parody 00:05:17.199 --> 00:05:22.240 disc that lets data from a single or two 00:05:20.320 --> 00:05:28.560 depending how many parody discs you have failed discs be rebuilt in the event of 00:05:25.120 --> 00:05:31.280 a less catastrophic failure. The problem 00:05:28.560 --> 00:05:37.039 is that while archive drives seem to be okay as standalone individual discs, the 00:05:34.400 --> 00:05:41.919 worst use case I could find for them was in parody protected RAID arrays with 00:05:39.919 --> 00:05:47.919 their poor random performance being pointed to as an unnecessary risk during 00:05:45.280 --> 00:05:52.960 a rebuild operation. So the data rebuilding process actually puts more 00:05:50.800 --> 00:05:58.320 strain than normal on the rest of the drives. And so the data across all the 00:05:55.759 --> 00:06:03.600 discs is in jeopardy until the corrupted or failed drives data has been rebuilt. 00:06:01.680 --> 00:06:09.440 So now we're 70% of the way through the video and we finally come to my idea. I 00:06:06.880 --> 00:06:15.759 figured by using archive drives in the array and an enterprise drive for parody 00:06:13.520 --> 00:06:21.680 and to replace any failed archive drives, I could mask both the poor 00:06:18.639 --> 00:06:25.280 random write performance and the slow 00:06:21.680 --> 00:06:27.199 rebuild times of the archive drives. And 00:06:25.280 --> 00:06:31.840 as you'll see from these performance numbers, it didn't work out that way at 00:06:29.520 --> 00:06:37.199 all. So uh my heterogeneous drive mixture configuration had worse 00:06:34.160 --> 00:06:41.039 performance than both all enterprise 00:06:37.199 --> 00:06:44.080 capacity drives which I expected and 00:06:41.039 --> 00:06:46.800 worse than a pure archive drive setup 00:06:44.080 --> 00:06:50.720 which I suspect is due to the mismatched disc spindle speed. So, that's kind of a 00:06:49.120 --> 00:06:55.600 drag, I guess. But there's some good news here for me anyway. And that is 00:06:53.120 --> 00:07:00.160 that in an unrade environment, I can either settle for 50 megabyte per second 00:06:58.319 --> 00:07:04.080 write speeds, about half of what a gigabit network can handle, in the 00:07:02.000 --> 00:07:08.000 default configuration where it spins up only the disc to which it's writing 00:07:05.759 --> 00:07:11.120 directly, and the parody disc to reduce power consumption and discare at the 00:07:09.520 --> 00:07:15.520 cost of performing read modify write operations all the time. Or if I use 00:07:13.199 --> 00:07:21.440 their turborite mode that spins all the discs during access, allowing for much 00:07:18.080 --> 00:07:23.759 faster reconstruct writes, I can still, 00:07:21.440 --> 00:07:28.720 even with the cheapest drives I could find that are rated for 247 operation, 00:07:26.560 --> 00:07:34.000 get my 100 megabytes per second since I'm not striping data the way that I 00:07:31.520 --> 00:07:38.560 would in a more traditional RAID, which to be clear, archive drives still are 00:07:36.560 --> 00:07:41.199 not recommended for. So, thanks for watching, guys. If this video sucked, 00:07:40.000 --> 00:07:45.759 you know what to do. But if it was awesome, get subscribed, hit that like button, or maybe even check out the link 00:07:44.479 --> 00:07:50.080 to where to buy the stuff that we featured at Amazon. In the video 00:07:47.759 --> 00:07:54.639 description, I have my full hard drive like NAS capacity and price calculator 00:07:52.639 --> 00:07:57.680 Excel sheet down there, which you can, you're more than welcome to try out. 00:07:56.319 --> 00:08:03.039 Also linked in the description is our merch store, which has cool shirts like this one, and our community forum, which 00:08:01.039 --> 00:08:06.720 you should totally join. Now that you're done doing all that stuff, you're probably wondering what to watch next. 00:08:05.280 --> 00:08:12.080 So, click that little button in the top right corner to check out our video from 00:08:09.520 --> 00:08:15.840 last year, which inspired a lot of this storage server stuff that I've been 00:08:13.520 --> 00:08:20.400 doing, where we lost pretty much all of our data 00:08:17.680 --> 00:08:22.800 temporarily. Or did I ruin the suspense? I don't know.