March 13, 201511 yr And I have a bunch of 2tb drives. Can an Areca 1231 create 8tb using 4x2tb in a raid 0 array for the parity disk? I'm waiting for preclearing to finish, and for Areca Arc-1110 to arrive, for exactly same purpose. Stay tuned
March 13, 201511 yr ... As for my 3 Seagates here - I imagine it's going to take "a loooong time" to do a continuous backup of my 12TB of data on the main server (unless because they are zerod the backup application I use writes the continuous backup sequentially??) and of course if it's continuous I get a nice sequential parity write too. It's unlikkey I'll have much regular file turnover - just weekly filling every Sunday so I'm hoping all is ok- proof as they say is in the pudding!! :-) I'd think there's an excellent change the backups will be written continuously, but as you noted the proof will be when you actually do it. The weekly backups will almost certainly be fine, as I doubt they'll exceed the persistent cache size.
March 13, 201511 yr And I have a bunch of 2tb drives. Can an Areca 1231 create 8tb using 4x2tb in a raid 0 array for the parity disk? Pretty sure the answer is yes.
March 16, 201511 yr There are ways! I have a RAID card that allows me to combine the capacities of two physical drives into a RAID0 volume that unRaid sees as a single large drive. With 2 4T drives, I could create a high performance 8T drive to use as parity. I created a RAID0 set on my Areca card with 2 4T drives. It's size is 7,814,036,428 k (taken from myMain detail view under "Size (k)" column). I believe that is substantially larger than a Seagate 8T SMR drive, but will leave to someone else to post that drive's size to verify.
March 16, 201511 yr ... I created a RAID0 set on my Areca card with 2 4T drives. ... What Areca model, if I may ask? I've tried Areca Arc-1110 (64Bit 133MHz PCI-X SATA II RAID) and it does not, it seems, support 4TB drives, although there is something like "use LBA for large disks" option in its setup. I've tried four (including Areca 1110) different old PCI-X RAID cards with two 4TB drives, resul'ting RAID0 was 3.6TB in size no matter what I did. They do successfully build 8TB RAID0 pool out of four 2TB drives, though.
March 16, 201511 yr What is your firmware version? I ugraded to 1.49 and you should also update to the latest available for your card.
March 16, 201511 yr What is your firmware version? Arrgh.. I did not even look I uploaded to 1.49 and you should also update to the latest available for your card. Will do... when the current preclear cycle finishes.
March 16, 201511 yr Arrgh.. I did not even look I uploaded to 1.49 and you should also update to the latest available for your card. Looks like there is a 1.49 version exists for your board. The "use LBA for large disks" applies to RAID arrays that the controller EXPOSES, not related to disks that it uses. You likely need the firmware update to support large disks. When you create the RAID0 array, you will use the RAID0 and large disk / "64 bit LBA" options. If there are other disks on the controller, you can use the pass through option on them.
March 16, 201511 yr Looks like there is a 1.49 version exists for your board. The "use LBA for large disks" applies to RAID arrays that the controller EXPOSES, not related to disks that it uses. You likely need the firmware update to support large disks. When you create the RAID0 array, you will use the RAID0 and large disk / "64 bit LBA" options. If there are other disks on the controller, you can use the pass through option on them. Thanks for the info. Yeah, I saw the 1.49 for ARC-1110 at areca.com It would be nice to have RAID card for PCI-X slot. Even if not, I still have the new Addonics AD4SA6GPX2 RAID card for PCIe, which should not have a problem creating 2x4TB=8TB pool.
March 22, 201511 yr These things have been out now for a bit; do we really not yet have conclusive evidence whether they are suited for media server storage? (Including a rebuild?) Thanks!
March 22, 201511 yr These things have been out now for a bit; do we really not yet have conclusive evidence whether they are suited for media server storage? (Including a rebuild?) Thanks! We have some evidence which shows its operating significantly better than some of our educated theorized behavior because of the unknown and unspecified at the time normal 25gb write band buffer zone. However the field experience conveyed so far all likely fell into the sequential write pattern behavior that is mitigated quite well. We dont have emperical evidence yet on what it truely takes in an unraid environment to get it to perform horribly like it did in the review in a normal raid rebuild.
March 22, 201511 yr Brit summarized what we know so far quite well. Seagate's design does an excellent job of mitigating the write penalties caused by band rewrites by implementing a 25GB "persistent cache" (a non-shingled cache on the disk) and having a large enough memory cache so the firmware "knows" if a series of writes are going to fill an entire band -- and can therefore skip both the cache AND the band rewrites in that case. These work VERY well at mitigating write penalties when most writes are large sequential files that don't require band rewrites. In virtually all the testing done so far by UnRAID users in this thread this has been the case -- so the drives have performed very well. Pre-clearing; parity sync; and drive rebuilds all tend to fall into this pattern. The big "unknown" is what will happen if you build up an array of these drives; and then do a lot of random writes to the array ... especially to multiple target drives. It seems fairly clear that if your usage pattern is that you never write more than 25GB at a time, they'll work just fine -- as even if you're writing a lot of small files, the persistent cache will "hide" the actual SLOW write speed to the bands, and the "catch up" moves to clear the persistent cache will occur while you're not actually using the array [same concept as when the Mover runs to move files off a cache drive]. But if you do a lot of > 25GB writes; then the jury's out on what the performance might be. We know enough now to speculate that it will be fine if all the files are large, but if they're small randomly located files things could definitely grind to a halt at some point (well, not actually a "halt" ... but a very severe slowdown). Overall, I think it's safe to say that these drives will perform much better than many of us anticipated based on the technological characteristics of the drives => thanks to a very good mitigation design by Seagate AND the typical usage pattern of most UnRAIDers => who tend to write large media files, which won't even use up much of the persistent cache space, since they'll bypass the band rewrite requirements.
March 22, 201511 yr Now if only we could get rid of those pages of posts where incorrect guesses were made.
March 22, 201511 yr Now if only we could get rid of those pages of posts where incorrect guesses were made. They were not incorrect guesses. They were informed conjecture based on the evidence at hand. That evidence is what was known and provided at the time by Seagate. It's not anyone's fault but Seagate's to have not disclosed all the facts, namely the specification including the 25GB of "persistent cache" and another large memory cache. Without this large non-shingled media and large memory buffer, the drive would perform as poorly as was speculated.
March 22, 201511 yr Agree with Brit => and Seagate STILL does not provide that information. The existence ... and the size ... of the persistent cache was determined through testing by 3rd parties who were testing the drives. Even Seagate's own video that shows the technology used makes NO mention of the mitigations of the issues that the video shows. Not sure why they held/hold this information so close to the chest => I assume it's considered "proprietary" ... but in any event I'm glad they did such a good job of mitigating the inherent problems
March 22, 201511 yr Brit summarized what we know so far quite well. Seagate's design does an excellent job of mitigating the write penalties caused by band rewrites by implementing a 25GB "persistent cache" (a non-shingled cache on the disk) and having a large enough memory cache so the firmware "knows" if a series of writes are going to fill an entire band -- and can therefore skip both the cache AND the band rewrites in that case. These work VERY well at mitigating write penalties when most writes are large sequential files that don't require band rewrites. In virtually all the testing done so far by UnRAID users in this thread this has been the case -- so the drives have performed very well. Pre-clearing; parity sync; and drive rebuilds all tend to fall into this pattern. The big "unknown" is what will happen if you build up an array of these drives; and then do a lot of random writes to the array ... especially to multiple target drives. It seems fairly clear that if your usage pattern is that you never write more than 25GB at a time, they'll work just fine -- as even if you're writing a lot of small files, the persistent cache will "hide" the actual SLOW write speed to the bands, and the "catch up" moves to clear the persistent cache will occur while you're not actually using the array [same concept as when the Mover runs to move files off a cache drive]. But if you do a lot of > 25GB writes; then the jury's out on what the performance might be. We know enough now to speculate that it will be fine if all the files are large, but if they're small randomly located files things could definitely grind to a halt at some point (well, not actually a "halt" ... but a very severe slowdown). Overall, I think it's safe to say that these drives will perform much better than many of us anticipated based on the technological characteristics of the drives => thanks to a very good mitigation design by Seagate AND the typical usage pattern of most UnRAIDers => who tend to write large media files, which won't even use up much of the persistent cache space, since they'll bypass the band rewrite requirements. The best post here, many thanks indeed for squashing down the basic understanding of what's known so far. Very disappointed with the "mods" here who have consistently taken this discussion off topic at every available turn. May I ask what your opinion is on the StorageReview review that mentions extreme performance penalties for RAID rebuilds in their test, and if there is a possibility there was a flaw in their testing and so forth? Many thanks in advance
March 23, 201511 yr May I ask what your opinion is on the StorageReview review that mentions extreme performance penalties for RAID rebuilds in their test, and if there is a possibility there was a flaw in their testing and so forth? I doubt there was any flaw in their testing. I suspect the RAID-5 rebuilds they did simply didn't result in writes in a patter that eliminated the use of the persistent cache and elimination of band rewrites. Remember that a RAID-5 is a striped array, so ALL of the drives were involved, and you didn't have a situation where a single drive was being written extensively and sequentially (as in UnRAID). Basically, the writes simply didn't "hit" the sweet spot for mitigation of the shingled overhead, so it hit the point where the persistent cache was full and everything slowed down to the true write speed that these can achieve when they have to do the band rewrites. As you noted, this is an extreme performance penalty, since the entire shingled band has to be read and then rewritten just to write a single sector (or cylinder, if the write is more than one sector). The StorageReview article does a good job of showing what CAN happen when writing to these drives if your usage pattern gets outside of the mitigation strategy that's incorporated in the drive's firmware. The best way to protect an UnRAID array from hitting this point is to use a non-shingled parity drive ... either a RAID-0 array of smaller drives or a PMR 8TB unit (which is currently very expensive). But as I noted above, for many usage scenarios, users probably won't get outside of the mitigation strategies that are embedded in the drives. Especially if you never write more than 25GB at once ... but also if you only write large files to a single drive when you exceed that.
March 23, 201511 yr ... and you didn't have a situation where a single drive was being written extensively and sequentially (as in UnRAID). Is this fact? Unraid rebuilds drives with sequential writes!?
March 23, 201511 yr I would expect so => think of the process: It reads ALL of the drives except the one it's rebuilding; then computes the appropriate data for the drive it's rebuilding and writes it. I'd certainly expect that it simply does this sequentially. Since the ONLY writes are to the drive being rebuilt, it's likely that this will be fast enough that the drive's firmware recognizes that it's writing full bands, and will thus write at full speed. Until somebody actually confirms this, it's speculative ... but I'm pretty confident it's correct.
March 23, 201511 yr Now if only we could get rid of those pages of posts where incorrect guesses were made. Exactly what I was thinking.
March 24, 201511 yr For anyone who is curious for a little more real world data, I just finished doing a preclear on my 8TB drive and a parity sync. ==1.15 == invoked as: ./preclear_disk.sh /dev/sdi == ST8000AS0002 == Disk /dev/sdi has been successfully precleared == with a starting sector of 1 == Ran 1 cycle == == Using :Read block size = 1000448 Bytes == Last Cycle's Pre Read Time : 19:51:11 (111 MB/s) == Last Cycle's Zeroing time : 16:11:00 (137 MB/s) == Last Cycle's Post Read Time : 38:09:00 (58 MB/s) == Last Cycle's Total Time : 74:16:25 == == Total Elapsed Time 74:16:25 == == Disk Start Temperature: 27C == == Current Disk Temperature: 33C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdi /tmp/smart_finish_sdi ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 116 100 6 ok 106094592 Seek_Error_Rate = 73 100 30 ok 21281058 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 Airflow_Temperature_Cel = 67 73 45 near_thresh 33 Temperature_Celsius = 33 27 0 ok 33 Hardware_ECC_Recovered = 116 100 0 ok 106094592 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ============================================================================ As for the people wondering about a disk rebuild using one of these, my array is 1x2TB, 3x3TB, 1x4TB and it took just under 12 hours to rebuild the newly precleared 8TB drive as my parity drive to get to the 4TB mark. Now that it's past the 4TB mark and only writing zeroes it's going at 168MB/s, so it should take less than 20 hours to fully rebuild.
March 24, 201511 yr For anyone who is curious for a little more real world data, I just finished doing a preclear on my 8TB drive and a parity sync. Can you post a full smartctl report on one of these drives. I wanted to look at the details on some of the sections.
March 24, 201511 yr Can you post a full smartctl report on one of these drives. I wanted to look at the details on some of the sections. Sure, I've never run a smartctl report though. Just give me a quick explanation of how to run one and I'll do it as soon as the parity sync finishes in ~7 hours.
March 24, 201511 yr preclear recorded the smart reports for you in /boot/preclear_reports/preclear_finish_<serial number>_<date>
March 24, 201511 yr Can you post a full smartctl report on one of these drives. I wanted to look at the details on some of the sections. Here you go: Disk: /dev/sdi smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.18.5-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: ST8000AS0002 Serial Number: LU WWN Device Id: Firmware Version: AR13 User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5980 rpm Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Mon Mar 23 20:05:01 2015 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 950) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x30a5) SCT Status supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 116 099 006 Pre-fail Always - 106094592 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 1 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 073 060 030 Pre-fail Always - 21281058 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 74 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 1 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 067 062 045 Old_age Always - 33 (Min/Max 24/38) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 3 194 Temperature_Celsius 0x0022 033 040 000 Old_age Always - 33 (0 24 0 0 0) 195 Hardware_ECC_Recovered 0x001a 116 099 000 Old_age Always - 106094592 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 12090332938314 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 15628053208 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 47784040788 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
Archived
This topic is now archived and is closed to further replies.