March 6, 201115 yr 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 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?
March 8, 201115 yr 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
March 13, 201115 yr 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.
March 14, 201115 yr 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 ]---
March 14, 201115 yr 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
March 15, 201115 yr 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.
March 15, 201115 yr 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)
March 15, 201115 yr 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.
March 15, 201115 yr 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.
March 15, 201115 yr 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.
March 15, 201115 yr 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.
March 15, 201115 yr 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.
March 16, 201115 yr 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?
March 16, 201115 yr 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.
March 16, 201115 yr 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 ]---
March 16, 201115 yr 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
March 18, 201115 yr 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
March 18, 201115 yr I built a new USB drive for my laptop and added pre_clear v1.8 to it, then pre cleared a firmware updated Samsung 2TB F4 disk via eSATA dock. It took 26 hours flat. I'm gonna start the next one tomorrow. :thumbsup: for eSATA and unRAID compatibility.
March 18, 201115 yr 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.
March 18, 201115 yr 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
March 18, 201115 yr 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...
March 19, 201115 yr 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.
Archived
This topic is now archived and is closed to further replies.