July 27, 201015 yr Admittedly, I'm fairly naive when it comes to using Telnet and more so Linux. I'm currently building a new unraid server and elected to PreClear a HDD from my test unraid server. It was probably about 20 hours in to the process when my wife logged in to the HTPC where I started the PreClear from a Telnet session and closed the window. Is there any way to restore the Telnet session and see its progress (if it is indeed continuing)? I simply did a Telnet session again and it went back to the Login. I don't think connecting a monitor to the server would allow me to see what the session is doing...correct?
July 27, 201015 yr I believe that as soon as the Telnet session was closed, the preclear session was canceled. Sorry. You can at least run just a partial preclear using the modifiers Joe L built into the script. See the bold text in the Preclear thread. Nothing wrong with running more than one preclear on a drive. Some people even chose to run multiple passes of preclear to be *extra* sure that a drive is good.
July 27, 201015 yr I usually preclear my new drives with 3 cycles to get a good baseline. I do this in putty if I have more than one drive so I can have multiple sessions running. If you are wanting to make sure the preclear session runs regardless of if you log off or not, you will need to physically get on the console and run it locally. Some of us use IPMI enabled systems that let us connect to the console remotely, and that's usually what I will do if I'm only preclearing one disk. I also use the mail option in the preclear to make sure I get emailed on the progress in case something kills the cycle.
July 27, 201015 yr There is also the screen program which lets you run sessions and willfully disconnect and reconnect on demand.
July 28, 201015 yr Author Thanks for the responses! It is a bummer that I just lost all that time, but oh well, live and learn. Ultimately, I did gain some time thought because I just didn't think of running concurrent sessions and doing more than one disk at a time. I think this is what I'll do to give my discs that I plan on putting in to my new unraid server a good start. Thanks again.
July 28, 201015 yr Author What temperatures do the hard drives normally maintain under this kind of load? My Samsung 2 TB drive seems to not exceed 39 degrees, but the WD 2 TB drive has remained at 42 degrees for some time. Normally, I wouldn't think much of it, but Preclear is highlighting the 42 degree temperature. Is it really something that I should be concerned about?
July 28, 201015 yr What temperatures do the hard drives normally maintain under this kind of load? My Samsung 2 TB drive seems to not exceed 39 degrees, but the WD 2 TB drive has remained at 42 degrees for some time. Normally, I wouldn't think much of it, but Preclear is highlighting the 42 degree temperature. Is it really something that I should be concerned about? Most people like to keep the temperatures below 40C. I would not worry too much about 42, but know it will get that high during a parity check or a re-construction too. If you can, provide more air flow across the drive. On my recently built (second) server: With the fans on low speed, the drives when sleeping are at 25 or 26 degrees C. When spinning, but not being accessed, they get to about 32C. When in heavy read/write use, they get up to 35C. With the fans on high speed, even in heavy use they only get to 30C, when spinning but idle, about 27C, and when sleeping about 25C (about the same as the ambient room temperature) Joe L.
July 28, 201015 yr Author Thanks Joe. I do have a place where I can add a fan that I think will help. Take care.
July 29, 201015 yr There is also the screen program which lets you run sessions and willfully disconnect and reconnect on demand. This is what I use and it allows you to do multiple preclears at once too.
July 29, 201015 yr What temperatures do the hard drives normally maintain under this kind of load? My Samsung 2 TB drive seems to not exceed 39 degrees, but the WD 2 TB drive has remained at 42 degrees for some time. Normally, I wouldn't think much of it, but Preclear is highlighting the 42 degree temperature. Is it really something that I should be concerned about? With a 120mm fan in front of my 4 drives I see about 30C on the 7200rpm Hitachis and 28C on the 5400rpm Samsungs. I think the general consensus is that anything below 40C average is acceptable. With the proper airflow it's amazing how easily they can be cooled.
July 30, 201015 yr Author Bummer...not exactly what I hoped for. This is a brand new WD 2TB drive. I am not sure if I fully understand the results. Can anyone help explain the extent of the issues here and whether or not they are truly significant? =========================================================================== = unRAID server Pre-Clear disk /dev/sdb = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Disk Temperature: 40C, Elapsed Time: 48:06:03 ============================================================================ == == Disk /dev/sdb has NOT been precleared successfully == skip=200 count=200 returned 40277 instead of 00000 skip=400 count=200 returne d 24123 instead of 00000 skip=600 count=200 returned 61325 instead of 00000 skip =800 count=200 returned 37227 instead of 00000 skip=1000 count=200 returned 1059 8 instead of 00000 skip=1200 count=200 returned 25385 instead of 00000 skip=1400 count=200 returned 47294 instead of 00000 skip=1600 count=200 returned 44504 in stead of 00000 skip=1800 count=200 returned 46770 instead of 00000 skip=2000 cou nt=200 returned 39089 instead of 00000 ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 19,20c19,20 < Offline data collection status: (0x82) Offline data collection activity < was completed without error. --- > Offline data collection status: (0x84) Offline data collection activity > was suspended by an interrupting command from host. 63c63 < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 377 --- > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 379 ============================================================================ root@Tower:/boot#
July 30, 201015 yr Unfortunately, the results are NOT very good. Although the drive "appears" to be returning good SMART results, it is NOT returning good data. The following lines are actually a cure for hair loss. (I'll explain in a minute) Disk /dev/sdb has NOT been precleared successfully == skip=200 count=200 returned 40277 instead of 00000 skip=400 count=200 returned 24123 instead of 00000 skip=600 count=200 returned 61325 instead of 00000 skip=800 count=200 returned 37227 instead of 00000 skip=1000 count=200 returned 10598 instead of 00000 skip=1200 count=200 returned 25385 instead of 00000 skip=1400 count=200 returned 47294 instead of 00000 skip=1600 count=200 returned 44504 instead of 00000 skip=1800 count=200 returned 46770 instead of 00000 skip=2000 count=200 returned 39089 instead of 00000 Each of the "blocks of data"read back by the post-clear "should" have returned all zeros, and their corresponding checksum also zero (00000) Instead 9 of the blocks returned something other than all zeros (and their checksum was therefore something other than zero) This could be caused by a bad disk, or, a bad power supply or a bad disk controller, or bad memory. All we know is we wrote all zeros, and read back other than zeros. If you had put this drive in your array, you would get random parity errors every time you did a parity check (as the drive returned occasional random bits) If you had not detected these errors on this disk at this time you would be pulling out your hair trying to figure out which disk was responsible. (parity errors do not tell you which disk is bad, just that parity across all of them is incorrect.) Since this test was specific to this disk, you know which disk is responsible, you might just have found the cure for some hair loss. (You'll not be pulling out your hair trying to find the disk causing the parity errors.) This is not the first time we've had a report of data written to a drive not being read back properly. This is about the third or fourth. Problem is, we do not know the actual cause. Is it a problem with the drive electronics on the disk drive? where bits are incorrectly being read. Is it a problem with the power supply and this disk is susceptible to power-supply-noise, and returning occasional random results? Is this a problem with the disk controller port? It is probably NOT a SATA cable issue, not unless you see in your SYSLOG a series of CRC errors in communicating with the drive. Since you did not mention them, either you did not look, or they were not occurring. You can try a different power cable, or a different SATA controller port to eliminate them. Sorry for the bad news, but the post-read should have found a completely zeroed drive and it did not. That specific test was added after one forum member lost a lot of hair. They eventually found a disk that would not return a good checksum on a file written to it in a completely different PC. (In other words, they isolated their occasional parity errors by physically isolating their drives, one at a time in a different PC, on a different version of Linux) They installed the disk in a different PC, copied a 4Gig file to the drive and read it back and the checksum was different, yet the SMART report was perfect. Joe L.
July 30, 201015 yr Author Wow, thanks Joe. This is really a huge help. I think what I have planned might offer some interesting results. The preclear was done on my test unraid server. It is made of mostly older components and what feels like band-aids to me just to get something up and running and familiarize myself with unraid. The motherboard uses the nForce2 Chipset (I think I read that isn't good, something to do with data issues), the power supply is a few years old, and the SATA controller card is PCI. Basically, while I was waiting on new equipment I thought I would do the preclear on this machine. I assumed anything it was doing was mostly local to the drive itself, but now I see I assumed wrong. Unfortunately, I am going out of town this weekend, but when I return I plan to finish up this new server with all new components mostly from the budget build. I'll do the preclear again and I'll be interested to see if the results differ at all. I'll be sure to reply with the results. Thanks again.
July 30, 201015 yr Author The other new 2TB Samsung drive just finished. The results seem somewhat similar to me. =========================================================================== = unRAID server Pre-Clear disk /dev/sda = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Disk Temperature: 38C, Elapsed Time: 52:41:32 ============================================================================ == == Disk /dev/sda has NOT been precleared successfully == skip=163000 count=200 returned 06168 instead of 00000 skip=163200 count=200 r eturned 14070 instead of 00000 skip=163600 count=200 returned 53259 instead of 0 0000 skip=164200 count=200 returned 04332 instead of 00000 skip=164800 count=200 returned 36873 instead of 00000 skip=165400 count=200 returned 40050 instead of 00000 skip=165600 count=200 returned 65267 instead of 00000 skip=165800 count=2 00 returned 50567 instead of 00000 skip=166000 count=200 returned 47008 instead of 00000 skip=166400 count=200 returned 60580 instead of 00000 ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 55c55 < 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 3 --- > 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 193 ============================================================================ root@Tower:/boot# ~
July 30, 201015 yr The other new 2TB Samsung drive just finished. The results seem somewhat similar to me. == Disk /dev/sda has NOT been precleared successfully == skip=163000 count=200 returned 06168 instead of 00000 skip=163200 count=200 r eturned 14070 instead of 00000 skip=163600 count=200 returned 53259 instead of 0 0000 skip=164200 count=200 returned 04332 instead of 00000 skip=164800 count=200 returned 36873 instead of 00000 skip=165400 count=200 returned 40050 instead of 00000 skip=165600 count=200 returned 65267 instead of 00000 skip=165800 count=2 00 returned 50567 instead of 00000 skip=166000 count=200 returned 47008 instead of 00000 skip=166400 count=200 returned 60580 instead of 00000 To me, that would point to something other than the drives being the cause. Perhaps the Nforce chipset as you described... We'll know for sure when you switch to the new hardware you've ordered. I'll be really curious, as it will help to confirm why those early Nforce chipset motherboards should be avoided. If I remember right the symptoms were random parity errors. (exactly the symptoms you would see if you used those drives in the current temporary hardware...) Just think, perhaps some of the crashes of early versions of Windows were not the fault of Microsoft..., but of the motherboard. Nah.... Joe L.
July 30, 201015 yr Author Just think, perhaps some of the crashes of early versions of Windows were not the fault of Microsoft..., but of the motherboard. Nah.... LOL!!!!! I gave it a bit more thought and since I have all the new equipment I really need except the power supply I went ahead and put things together. Again, I'm going out of town so if the preclear is successful this time it will save me some time. I'm only using a somewhat dated power supply to power it. Everything else is brand new except the case. The build is simply identical to the budget build (outside of what I've already mentioned). I added a 120mm fan near where the hard drives are. It has 3 speed settings and I set it at its highest settings. This appears to have greatly improved the temperatures of the drives. With the WD holding at around 34 degrees during the preread and the Samsung at 30 degrees. Both drives are resulting in faster read times on this new server with both of them resulting in around 94 MB/sec. Again, I'll reply back in about 48 hours once I have the results of both preclears.
July 30, 201015 yr As a side note, your drives are taking a VERY long time to finish a cycle. Comparatively, my Hitachis do it in about 30 hours, and my Samsungs do it in 36 hours.
July 30, 201015 yr Author As a side note, your drives are taking a VERY long time to finish a cycle. Comparatively, my Hitachis do it in about 30 hours, and my Samsungs do it in 36 hours. This is really good to know aiden. I thought for sure the new hardware would help speeds things up here and for the Samsung drive I think it has. However, something does not look right with the WD drive. It seems to be moving at exactly half the speed of the Samsung drive and has been for hours. I started the preclear at the exact same time on both drives. See attachment.
July 31, 201015 yr 51.5 MB/s on the outer 1/3 of the platter is pitifully slow. Even if that is a 5400 rpm drive, at that location on the disk you should be seeing at least 70s. There are numerous possibilities for the slowdown, like a bad sata cable, bad controller port, or simply a bad drive. I'm sure Joe or Weebo will have a much more succinct theory than I do. But I would at least look at trying a simple cable swap and seeing if that changes anything.
July 31, 201015 yr Author Thanks aiden. It certainly seemed like something was wrong to me as well. It seems to only be attributed to writing on the WD drive. Both drives are now at the post-read stage and they are both performing at about the same level (~80 MB/sec).
July 31, 201015 yr You have one of your disk controllers set in your BIOS to emulate an IDE drive in an legacy mode. It is why the disk is showing as /dev/hdb instead of /dev/sdX. That emulation of an old master/slave controller in the BIOS is there so the motherboard can boot older Windows operating systems. They have no SATA drivers and therefore would not be able to boot if they did not (think they) see an IDE hard disk. We have no need for that kind of IDE emulation, and in fact, it might be causing the slower performance. You should set the BIOS to ACHI mode for the SATA disk controllers.
July 31, 201015 yr Author Great catch Joe. Thank you. I won't be able to update it and do another preclear until I return from out of town (tomorrow). I guess this does have me wondering though, could the preclear succeed without ACHI on this drive? If so, I assume I wouldn't need to do it again, would I?
July 31, 201015 yr Great catch Joe. Thank you. I won't be able to update it and do another preclear until I return from out of town (tomorrow). I guess this does have me wondering though, could the preclear succeed without ACHI on this drive? If so, I assume I wouldn't need to do it again, would I? You would not need to do it again. Joe L.
July 31, 201015 yr However, something does not look right with the WD drive. It seems to be moving at exactly half the speed of the Samsung drive and has been for hours. I started the preclear at the exact same time on both drives. What model of WD drive is it? If it is a WDxxEARS, then slow writes could be the result of misaligned sectors because of the 'Advanced' format. With an EARS drive, it is important to install a configuration jumper on pins 7-8.
July 31, 201015 yr Author However, something does not look right with the WD drive. It seems to be moving at exactly half the speed of the Samsung drive and has been for hours. I started the preclear at the exact same time on both drives. What model of WD drive is it? If it is a WDxxEARS, then slow writes could be the result of misaligned sectors because of the 'Advanced' format. With an EARS drive, it is important to install a configuration jumper on pins 7-8. Thanks. I made it a point to avoid the EARS drive. I don't think there is anything wrong with using it with the jumpers, but I figured it was one less thing to think about and I did have a choice of other drives. It is actually the EADS WD 2TB drive. I think Joe L. nailed it with the ACHI. I just would have thought it was enabled by default. Once I do enable it I suspect it will have similar performance to the Samsung drive.
Archived
This topic is now archived and is closed to further replies.