Re: preclear_disk.sh - a new utility to burn-in and pre-clear disks for quick add


Recommended Posts

sorry if this has been asked, i tried searching for it but one of the keywords is "smart" and it gave me 7 pages of results in this thread alone :P

 

Im trying to preclear some of my HDDs that are connected to a LSI SATA/SAS card.

 

Drives on that don't report any smart data, so when running pre-clear it fails straight away.

Is there a way to skip the SMART testing?

Link to comment

Is there a way to gracefully shut down the preclear script once running? Or should I just ctrl-C out? I have a drive that's preclearing and its about to finish one cycle. I have another disk I would like to preclear, as well, but the first one has another cycle to go. The second one is failing the SMART test at the start of preclearing (see attachment), but run from terminal I get a normal SMART report (see attachment). I think I need to power cycle things to get the preclear to run correctly on this second disk. Or maybe there is something else going on?

 

Edit: well, I shut down the array and restarted, no joy. Still get the same error when trying to invoke pre clear script. Even stranger, the drive is being reported as a 1T drive ( it's a 1.5T). tried to pre clear with option "-D", same error. Not sure what's going on. Would it be worth it to pull it, reformat, and try again?

 

This may be related to the troubles recently reported with the pre clear script and the SuperMicro SAS controller card. I'll move to that discussion.

preclear_Error.txt

SMART_Report.txt

Link to comment

Version 1.8 is now attached to the first post in this thread.  It may help those who are now getting an error when trying to run it on some disks and disk controllers.

 

In version 1.7 I had added a preliminary test using "smartctl" before performing any clearing steps.  This has stopped the preclear process from operating on some disks/disk controllers as they do not completely support the SMART command set.

 

In version 1.8 this test is still present but you'll be prompted to continue in the event of a non-standard output status.  You'll be able to respond with Yes and start the preclearing as desired.

 

I've also slightly changed the way I calculate random sectors on a disk in pre-read and post-read phrases.  We'll see if it keeps some drives from locking up. 

 

Joe L.

Link to comment

Thanks Joe.  Perfect timing.  It appears to have fix my previous problems and my earlier lockups.  Is this normal/ok?

 

Mar 13 21:21:06 Hitch kernel:  sdb: sdb1
Mar 13 21:22:42 Hitch kernel: ------------[ cut here ]------------
Mar 13 21:22:42 Hitch kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308()
Mar 13 21:22:42 Hitch kernel: Hardware name: A760G M2+
Mar 13 21:22:42 Hitch kernel: Modules linked in: tun md_mod xor atiixp ahci r8169 mvsas libsas scst scsi_transport_sas
Mar 13 21:22:42 Hitch kernel: Pid: 25832, comm: hdparm Not tainted 2.6.32.9-unRAID #8
Mar 13 21:22:42 Hitch kernel: Call Trace:
Mar 13 21:22:42 Hitch kernel:  [<c102449e>] warn_slowpath_common+0x60/0x77
Mar 13 21:22:42 Hitch kernel:  [<c10244c2>] warn_slowpath_null+0xd/0x10
Mar 13 21:22:42 Hitch kernel:  [<c11b624d>] ata_qc_issue+0x10b/0x308
Mar 13 21:22:42 Hitch kernel:  [<c11ba260>] ata_scsi_translate+0xd1/0xff
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7
Mar 13 21:22:42 Hitch kernel:  [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d
Mar 13 21:22:42 Hitch kernel:  [<f843369a>] sas_queuecommand+0x65/0x20d [libsas]
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181
Mar 13 21:22:42 Hitch kernel:  [<c11ace4d>] scsi_request_fn+0x351/0x376
Mar 13 21:22:42 Hitch kernel:  [<c1126798>] __blk_run_queue+0x78/0x10c
Mar 13 21:22:42 Hitch kernel:  [<c1124446>] elv_insert+0x67/0x153
Mar 13 21:22:42 Hitch kernel:  [<c11245b8>] __elv_add_request+0x86/0x8b
Mar 13 21:22:42 Hitch kernel:  [<c1129343>] blk_execute_rq_nowait+0x4f/0x73
Mar 13 21:22:42 Hitch kernel:  [<c11293dc>] blk_execute_rq+0x75/0x91
Mar 13 21:22:42 Hitch kernel:  [<c11292cc>] ? blk_end_sync_rq+0x0/0x28
Mar 13 21:22:42 Hitch kernel:  [<c112636f>] ? get_request+0x204/0x28d
Mar 13 21:22:42 Hitch kernel:  [<c11269d6>] ? get_request_wait+0x2b/0xd9
Mar 13 21:22:42 Hitch kernel:  [<c112c2bf>] sg_io+0x22d/0x30a
Mar 13 21:22:42 Hitch kernel:  [<c112c5a8>] scsi_cmd_ioctl+0x20c/0x3bc
Mar 13 21:22:42 Hitch kernel:  [<c11b3257>] sd_ioctl+0x6a/0x8c
Mar 13 21:22:42 Hitch kernel:  [<c112a420>] __blkdev_driver_ioctl+0x50/0x62
Mar 13 21:22:42 Hitch kernel:  [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc
Mar 13 21:22:42 Hitch kernel:  [<c1131e2d>] ? kobject_get+0x12/0x17
Mar 13 21:22:42 Hitch kernel:  [<c112b0f8>] ? get_disk+0x4a/0x61
Mar 13 21:22:42 Hitch kernel:  [<c101b028>] ? kmap_atomic+0x14/0x16
Mar 13 21:22:42 Hitch kernel:  [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf
Mar 13 21:22:42 Hitch kernel:  [<c104a179>] ? filemap_fault+0xb8/0x305
Mar 13 21:22:42 Hitch kernel:  [<c1048c43>] ? unlock_page+0x18/0x1b
Mar 13 21:22:42 Hitch kernel:  [<c1057c63>] ? __do_fault+0x3a7/0x3da
Mar 13 21:22:42 Hitch kernel:  [<c105985f>] ? handle_mm_fault+0x42d/0x8f1
Mar 13 21:22:42 Hitch kernel:  [<c108b6c6>] block_ioctl+0x2a/0x32
Mar 13 21:22:42 Hitch kernel:  [<c108b69c>] ? block_ioctl+0x0/0x32
Mar 13 21:22:42 Hitch kernel:  [<c10769d5>] vfs_ioctl+0x22/0x67
Mar 13 21:22:42 Hitch kernel:  [<c1076f33>] do_vfs_ioctl+0x478/0x4ac
Mar 13 21:22:42 Hitch kernel:  [<c105dcdd>] ? do_mmap_pgoff+0x232/0x294
Mar 13 21:22:42 Hitch kernel:  [<c1076f93>] sys_ioctl+0x2c/0x45
Mar 13 21:22:42 Hitch kernel:  [<c1002935>] syscall_call+0x7/0xb
Mar 13 21:22:42 Hitch kernel: ---[ end trace 7f1e9f192190e675 ]---

Link to comment

I thought I would give the new version a try to see if the issues I was having when trying to preclear a drive connected to the SASLP-MV8 card would be resolved with the latest release.

I hooked up an empty drive which had aleady been precleared using an Adaptec 1430 - see report below:

========================================================================1.7
== invoked as: ./preclear_disk.sh -A /dev/sdj
==  ST2000DL003-9VT166    5YD1BNYS
== Disk /dev/sdj has been successfully precleared
== with a starting sector of 64 
== Ran 1 cycle
==
== Using :Read block size = 8225280 Bytes
== Last Cycle's Pre Read Time  : 6:05:35 (91 MB/s)
== Last Cycle's Zeroing time   : 5:23:41 (103 MB/s)
== Last Cycle's Post Read Time : 16:26:32 (33 MB/s)
== Last Cycle's Total Time     : 27:56:54
==
== Total Elapsed Time 27:56:54
==
== Disk Start Temperature: 26C
==
== Current Disk Temperature: 30C, 
==
============================================================================
** Changed attributes in files: /tmp/smart_start_sdj  /tmp/smart_finish_sdj
               ATTRIBUTE   NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS      RAW_VALUE
     Raw_Read_Error_Rate =   105     117            6        ok          10484760
         Seek_Error_Rate =    60     100           30        ok          1013495
        Spin_Retry_Count =   100     100           97        near_thresh 0
        End-to-End_Error =   100     100           99        near_thresh 0
         High_Fly_Writes =    99     100            0        ok          1
 Airflow_Temperature_Cel =    70      74           45        near_thresh 30
     Temperature_Celsius =    30      26            0        ok          30
  Hardware_ECC_Recovered =    37      27            0        ok          10484760
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. 
============================================================================

Preclear is now working with this drive on the SASLP port   I think...

But I also got the same messages in the sys log:

Mar 14 21:10:39 Tower2 login[4408]: ROOT LOGIN on `pts/0' from `192.168.1.101' (Logins)
Mar 14 21:11:59 Tower2 ata_id[5149]: HDIO_GET_IDENTITY failed for '/dev/block/8:112' (Minor Issues)
Mar 14 21:11:59 Tower2 kernel: sdh: sdh1 (Drive related)
Mar 14 21:12:39 Tower2 kernel: ------------[ cut here ]------------
Mar 14 21:12:39 Tower2 kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308() (Minor Issues)
Mar 14 21:12:39 Tower2 kernel: Hardware name: System Product Name
Mar 14 21:12:39 Tower2 kernel: Modules linked in: md_mod xor i2c_i801 i2c_core r8169 pata_jmicron jmicron ahci sata_mv mvsas libsas scst scsi_transport_sas (Drive related)
Mar 14 21:12:39 Tower2 kernel: Pid: 5600, comm: hdparm Not tainted 2.6.32.9-unRAID #8 (Errors)
Mar 14 21:12:39 Tower2 kernel: Call Trace: (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c102449e>] warn_slowpath_common+0x60/0x77 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c10244c2>] warn_slowpath_null+0xd/0x10 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11b624d>] ata_qc_issue+0x10b/0x308 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11ba260>] ata_scsi_translate+0xd1/0xff (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11a816c>] ? scsi_done+0x0/0xd (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11a816c>] ? scsi_done+0x0/0xd (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d (Errors)
Mar 14 21:12:39 Tower2 kernel: [<f842869a>] sas_queuecommand+0x65/0x20d [libsas] (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11a816c>] ? scsi_done+0x0/0xd (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11ace4d>] scsi_request_fn+0x351/0x376 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1126798>] __blk_run_queue+0x78/0x10c (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1124446>] elv_insert+0x67/0x153 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11245b8>] __elv_add_request+0x86/0x8b (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1129343>] blk_execute_rq_nowait+0x4f/0x73 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11293dc>] blk_execute_rq+0x75/0x91 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11292cc>] ? blk_end_sync_rq+0x0/0x28 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112636f>] ? get_request+0x204/0x28d (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11269d6>] ? get_request_wait+0x2b/0xd9 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112c2bf>] sg_io+0x22d/0x30a (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112c5a8>] scsi_cmd_ioctl+0x20c/0x3bc (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11b3257>] sd_ioctl+0x6a/0x8c (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112a420>] __blkdev_driver_ioctl+0x50/0x62 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c112b0f8>] ? get_disk+0x4a/0x61 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c101b028>] ? kmap_atomic+0x14/0x16 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c104a179>] ? filemap_fault+0xb8/0x305 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1048c43>] ? unlock_page+0x18/0x1b (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1057c63>] ? __do_fault+0x3a7/0x3da (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c105985f>] ? handle_mm_fault+0x42d/0x8f1 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c108b6c6>] block_ioctl+0x2a/0x32 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c108b69c>] ? block_ioctl+0x0/0x32 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c10769d5>] vfs_ioctl+0x22/0x67 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1076f33>] do_vfs_ioctl+0x478/0x4ac (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c105dcdd>] ? do_mmap_pgoff+0x232/0x294 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1076f93>] sys_ioctl+0x2c/0x45 (Errors)
Mar 14 21:12:39 Tower2 kernel: [<c1002935>] syscall_call+0x7/0xb (Errors)
Mar 14 21:12:39 Tower2 kernel: ---[ end trace 2a0acd6c3ce8f845 ]---

I assume these do NOT effect the preclear process and/or unraid operation?

Thanks

Link to comment

It does appear that my drive (that was connected to a SASLP-MV8) precleard correctly in good time I might add.  I couldn't get a full report due to not having enough room on my flash drive.

 

I then hooked that same drive to a different port on that card along with another drive on another port on the same card and preclear locked up and filled the syslog with errors.  I then left one of the drives in and although it listed as an available drive to preclear, this is the message I got:

 

Sorry: dev/sdb does not exist as a block device
Clearing will NOT be performed

 

Sorry, I couldn't grab any logs and had to leave for work.

Link to comment

It does appear that my drive (that was connected to a SASLP-MV8) precleard correctly in good time I might add.  I couldn't get a full report due to not having enough room on my flash drive.

 

I then hooked that same drive to a different port on that card along with another drive on another port on the same card and preclear locked up and filled the syslog with errors.  I then left one of the drives in and although it listed as an available drive to preclear, this is the message I got:

 

Sorry: dev/sdb does not exist as a block device
Clearing will NOT be performed

 

Sorry, I couldn't grab any logs and had to leave for work.

That is true..

 

dev/sdb does not exist in your current directory as a block device, and probably does not exist at all.

/dev/sdb probably does exist.  (note the leading "/" in the path)

Link to comment

I'll try it again, but I thought I tried it with /dev/sdb as well as /dev/sdb/

 

I was in a hurry this morning so who knows.

 

Any clue why the lockup might have occured or anything I can send to you that might help.

 

Edit:  I was able to run it with the /dev/sdb command.  Must have been in too big of a hurry.  It locks up and here are a few of the syslog entries:

 

Mar 15 17:28:06 Hitch kernel: end_request: I/O error, dev sdb, sector 9346240 (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)

 

Let me know if there is anything else I can provide.

Link to comment

I'll try it again, but I thought I tried it with /dev/sdb as well as /dev/sdb/

 

I was in a hurry this morning so who knows.

 

Any clue why the lockup might have occured or anything I can send to you that might help.

 

Edit:  I was able to run it with the /dev/sdb command.  Must have been in too big of a hurry.  It locks up and here are a few of the syslog entries:

 

Mar 15 17:28:06 Hitch kernel: end_request: I/O error, dev sdb, sector 9346240 (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)
Mar 15 17:28:06 Hitch kernel: ata1: status=0x41 { DriveReady Error } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: error=0x04 { DriveStatusError } (Errors)
Mar 15 17:28:06 Hitch kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)

 

Let me know if there is anything else I can provide.

 

Doing a google search on

ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ

results in lots of other reports of the same errors, probably related to the device driver involved.

 

That does not fix it, but at least you know you are not alone.

Link to comment

Joe, running preclear_disk version 1.7 on unRaid 5.0 Beta6a.  The default partition format is 4K aligned.  Called with

"preclear_disk -c 2 /dev/sdc" (no -a or -A).  Cycle 1 ran with partition start 64.  Cycle 2 is running with partition start 63.

 

If its significant, there are no disks assigned to the array.

Link to comment

Running preclear_disk version 1.7 on unRaid 5.0 Beta6a.  The default partition format is 4K aligned.  Called with

"preclear_disk -c 2 /dev/sdc" (no -a or -A).  Cycle 1 ran with partition start 64.  Cycle 2 is running with partition start 63.

Interesting...

 

I don't doubt you, but I see no way for that to occur...  (In other words, I'll have to test it myself)

If running with no option specified the "default" will be that you've specified in the unRAID "Settings" page.

 

The partition start is set prior to entering the "cycle" loop.  It is un-changed (as far as I know) otherwise.

 

Before I start my test,  are you sure you have 4k-aligned as the "default" set on your server?    (please double-check, so I can duplicate your situation here)

 

Also, once the second cycle is complete, let me know what the output says.  You might even run

preclear_disk.sh -t /dev/sdc

and let it tell you how the disk is partitioned.  I'll be curious what it says.

 

Joe L.

Link to comment

I just got the RMA replacement for one of my drives and started running preclear on it.

 

I'm hearing seek noises from this recertified EARS just a tad louder than to my liking, and since I'm a bit of a paranoia, I'm wondering if there's anything wrong with it, considering it's recertified. I did a short smart test before running preclear and everything looked fine. I know the preclear script is very intensive on the hard drives - would that be the cause of the louder seek noises? As a comparison, the noise level is about the same (or just a tad quieter) as when my 120GB Maxtor (7 years old and still running perfectly fine!) would sound when Windows XP boots up. It's just that.. the rest of my EADS and Seagate Green drives were virtually silent during preclear.

 

I'll wait and see what happens at the end of the preclear. BTW, does preclear run the short or long smart test?

 

Would you trust your parity on a recertified? That was what this drive was intended to replace.

Link to comment

Running preclear_disk version 1.7 on unRaid 5.0 Beta6a.  The default partition format is 4K aligned.  Called with

"preclear_disk -c 2 /dev/sdc" (no -a or -A).  Cycle 1 ran with partition start 64.  Cycle 2 is running with partition start 63.

Interesting...

 

I don't doubt you, but I see no way for that to occur...   (In other words, I'll have to test it myself)

If running with no option specified the "default" will be that you've specified in the unRAID "Settings" page.

 

The partition start is set prior to entering the "cycle" loop.  It is un-changed (as far as I know) otherwise.

 

Before I start my test,  are you sure you have 4k-aligned as the "default" set on your server?    (please double-check, so I can duplicate your situation here)

 

Also, once the second cycle is complete, let me know what the output says.   You might even run

preclear_disk.sh -t /dev/sdc

and let it tell you how the disk is partitioned.  I'll be curious what it says.

 

Joe L.

 

The default is 4k-Aligned.  I'll run -t when the cycle is done.  Also, the server isn't needed at the moment.  I'll repeat the 2-cycle test to verify.  Any files that would be of use?

Link to comment

I just got the RMA replacement for one of my drives and started running preclear on it.

 

I'm hearing seek noises from this recertified EARS just a tad louder than to my liking, and since I'm a bit of a paranoia, I'm wondering if there's anything wrong with it, considering it's recertified. I did a short smart test before running preclear and everything looked fine. I know the preclear script is very intensive on the hard drives - would that be the cause of the louder seek noises? As a comparison, the noise level is about the same (or just a tad quieter) as when my 120GB Maxtor (7 years old and still running perfectly fine!) would sound when Windows XP boots up. It's just that.. the rest of my EADS and Seagate Green drives were virtually silent during preclear.

 

I'll wait and see what happens at the end of the preclear. BTW, does preclear run the short or long smart test?

 

Would you trust your parity on a recertified? That was what this drive was intended to replace.

 

If it helps any, I have two 2TB EARS drives and I cannot hear them at all. My unRaid server is very quiet as well.

Link to comment

Doing a google search on

ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ

results in lots of other reports of the same errors, probably related to the device driver involved.

 

That does not fix it, but at least you know you are not alone.

 

So are you saying there is a problem with the unraid driver for the SASLP-MV8 card?  I haven't been having great luck with it lately.  I even switched from a Asus MB to a recommended Biostar one because of it.

 

I took the same drive and pre_clear is working on it via the onboard sata port.  This was the message I received in the syslog in regards to it:

 

 

Mar 13 21:22:42 Hitch kernel: ------------[ cut here ]------------
Mar 13 21:22:42 Hitch kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308()
Mar 13 21:22:42 Hitch kernel: Hardware name: A760G M2+
Mar 13 21:22:42 Hitch kernel: Modules linked in: tun md_mod xor atiixp ahci r8169 mvsas libsas scst scsi_transport_sas
Mar 13 21:22:42 Hitch kernel: Pid: 25832, comm: hdparm Not tainted 2.6.32.9-unRAID #8
Mar 13 21:22:42 Hitch kernel: Call Trace:
Mar 13 21:22:42 Hitch kernel:  [<c102449e>] warn_slowpath_common+0x60/0x77
Mar 13 21:22:42 Hitch kernel:  [<c10244c2>] warn_slowpath_null+0xd/0x10
Mar 13 21:22:42 Hitch kernel:  [<c11b624d>] ata_qc_issue+0x10b/0x308
Mar 13 21:22:42 Hitch kernel:  [<c11ba260>] ata_scsi_translate+0xd1/0xff
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7
Mar 13 21:22:42 Hitch kernel:  [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d
Mar 13 21:22:42 Hitch kernel:  [<f843369a>] sas_queuecommand+0x65/0x20d [libsas]
Mar 13 21:22:42 Hitch kernel:  [<c11a816c>] ? scsi_done+0x0/0xd
Mar 13 21:22:42 Hitch kernel:  [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181
Mar 13 21:22:42 Hitch kernel:  [<c11ace4d>] scsi_request_fn+0x351/0x376
Mar 13 21:22:42 Hitch kernel:  [<c1126798>] __blk_run_queue+0x78/0x10c
Mar 13 21:22:42 Hitch kernel:  [<c1124446>] elv_insert+0x67/0x153
Mar 13 21:22:42 Hitch kernel:  [<c11245b8>] __elv_add_request+0x86/0x8b
Mar 13 21:22:42 Hitch kernel:  [<c1129343>] blk_execute_rq_nowait+0x4f/0x73
Mar 13 21:22:42 Hitch kernel:  [<c11293dc>] blk_execute_rq+0x75/0x91
Mar 13 21:22:42 Hitch kernel:  [<c11292cc>] ? blk_end_sync_rq+0x0/0x28
Mar 13 21:22:42 Hitch kernel:  [<c112636f>] ? get_request+0x204/0x28d
Mar 13 21:22:42 Hitch kernel:  [<c11269d6>] ? get_request_wait+0x2b/0xd9
Mar 13 21:22:42 Hitch kernel:  [<c112c2bf>] sg_io+0x22d/0x30a
Mar 13 21:22:42 Hitch kernel:  [<c112c5a8>] scsi_cmd_ioctl+0x20c/0x3bc
Mar 13 21:22:42 Hitch kernel:  [<c11b3257>] sd_ioctl+0x6a/0x8c
Mar 13 21:22:42 Hitch kernel:  [<c112a420>] __blkdev_driver_ioctl+0x50/0x62
Mar 13 21:22:42 Hitch kernel:  [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc
Mar 13 21:22:42 Hitch kernel:  [<c1131e2d>] ? kobject_get+0x12/0x17
Mar 13 21:22:42 Hitch kernel:  [<c112b0f8>] ? get_disk+0x4a/0x61
Mar 13 21:22:42 Hitch kernel:  [<c101b028>] ? kmap_atomic+0x14/0x16
Mar 13 21:22:42 Hitch kernel:  [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf
Mar 13 21:22:42 Hitch kernel:  [<c104a179>] ? filemap_fault+0xb8/0x305
Mar 13 21:22:42 Hitch kernel:  [<c1048c43>] ? unlock_page+0x18/0x1b
Mar 13 21:22:42 Hitch kernel:  [<c1057c63>] ? __do_fault+0x3a7/0x3da
Mar 13 21:22:42 Hitch kernel:  [<c105985f>] ? handle_mm_fault+0x42d/0x8f1
Mar 13 21:22:42 Hitch kernel:  [<c108b6c6>] block_ioctl+0x2a/0x32
Mar 13 21:22:42 Hitch kernel:  [<c108b69c>] ? block_ioctl+0x0/0x32
Mar 13 21:22:42 Hitch kernel:  [<c10769d5>] vfs_ioctl+0x22/0x67
Mar 13 21:22:42 Hitch kernel:  [<c1076f33>] do_vfs_ioctl+0x478/0x4ac
Mar 13 21:22:42 Hitch kernel:  [<c105dcdd>] ? do_mmap_pgoff+0x232/0x294
Mar 13 21:22:42 Hitch kernel:  [<c1076f93>] sys_ioctl+0x2c/0x45
Mar 13 21:22:42 Hitch kernel:  [<c1002935>] syscall_call+0x7/0xb
Mar 13 21:22:42 Hitch kernel: ---[ end trace 7f1e9f192190e675 ]---

Link to comment

I just got the RMA replacement for one of my drives and started running preclear on it.

 

I'm hearing seek noises from this recertified EARS just a tad louder than to my liking, and since I'm a bit of a paranoia, I'm wondering if there's anything wrong with it, considering it's recertified. I did a short smart test before running preclear and everything looked fine. I know the preclear script is very intensive on the hard drives - would that be the cause of the louder seek noises? As a comparison, the noise level is about the same (or just a tad quieter) as when my 120GB Maxtor (7 years old and still running perfectly fine!) would sound when Windows XP boots up. It's just that.. the rest of my EADS and Seagate Green drives were virtually silent during preclear.

 

I'll wait and see what happens at the end of the preclear. BTW, does preclear run the short or long smart test?

 

Would you trust your parity on a recertified? That was what this drive was intended to replace.

 

If it helps any, I have two 2TB EARS drives and I cannot hear them at all. My unRaid server is very quiet as well.

 

It's in the Post-read portion of the preclear now and I can't hear any seeking anymore, it was only audible during pre-read. Weird. Let's see how the SMART tests say :)

 

Seriously, I'm being extra paranoid here because it's a re-certified RMA replacement. My last RMA from WD was a new drive :(

Link to comment

I have an older preclear_disk.sh script with verison 4.5.6. I am going to upgrade to 4.7 and need to download an updated preclear_disk.sh script. I am logged into the forum, but I haven't been able to find the download anywhere, in utilities, or anywhere else.

 

Dave

It is attached to the first post in this thread:

http://lime-technology.com/forum/index.php?topic=2817.0

 

You must be logged in to see the attachment. 

 

Joe L.

Link to comment

I have an older preclear_disk.sh script with verison 4.5.6. I am going to upgrade to 4.7 and need to download an updated preclear_disk.sh script. I am logged into the forum, but I haven't been able to find the download anywhere, in utilities, or anywhere else.

 

Dave

It is attached to the first post in this thread:

http://lime-technology.com/forum/index.php?topic=2817.0

 

You must be logged in to see the attachment.   

 

Joe L.

 

The preclear script download used to work that way for me. Months ago, when I was not logged in, I did not see the download. I then I logged in and saw the download. Now, the download never displays, even though I am logged in. I think that part of the web site is not working anymore. So, the download is never visible for me. I am attaching a screenshot, so you can see there is no visible download when I am logged in.

 

Dave

preclear-script.zip

Link to comment

I have an older preclear_disk.sh script with verison 4.5.6. I am going to upgrade to 4.7 and need to download an updated preclear_disk.sh script. I am logged into the forum, but I haven't been able to find the download anywhere, in utilities, or anywhere else.

 

Dave

It is attached to the first post in this thread:

http://lime-technology.com/forum/index.php?topic=2817.0

 

You must be logged in to see the attachment.   

 

Joe L.

 

The preclear script download used to work that way for me. Months ago, when I was not logged in, I did not see the download. I then I logged in and saw the download. Now, the download never displays, even though I am logged in. I think that part of the web site is not working anymore. So, the download is never visible for me. I am attaching a screenshot, so you can see there is no visible download when I am logged in.

 

Dave

The download link is at the very bottom of that long first post.  ( I just looked, it is still there)

 

Your screen shot shows the top of that first post.

 

Scroll down...

Link to comment

Version 1.9 is now attached to the first post in this thread. 

 

It fixes two issues.

One was a difference in how values are stored differently in 4.7 and prior vs. 5.0.  (in 5.0+ the values are surrounded by quotes)

This prevented preclear from detecting the default partition alignment setting on 5.0beta versions of unRAID.    This only showed itself if you did not specify "-a" or "-A" on the command line.

 

The other was sometimes excluding an extra drive when using the "-l" command.  (it did not show as a potential candidate for clearing)

 

Joe L.

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.