Joe L.

For that particular model of disk, the "Load_Cycle_Count" raw value seems to be incremented by one each time the disk heads are taken out of the "parked" position. Of the three columns of values, the first is the current value, the second is the worst value (lowest ever encountered) and the third is the failure threshold. For "Load_cycle_count" the disk will be considered as "failed" when the current value reached zero. At that point, the disk will be considered to be "worn out" by the firmware. (I'm guessing here... but the math almost looks like it might work something like this) Let's theorize that for that disk, the "current value" starts when the disk is brand new at 200. Let's also guess that every 3000 "load-cycles" will decrement the "Current" value by 1. If we used those... the numbers come out somewhat close... If I was a manufacturer, I'd use powers of 2 and divide by 1024, but you get the idea. Each manufacturer has their own internal algorithm... Using my math, you have over 500,000 more head-load cycles before the overall wear and tear on the drive is expected to be an issue. Of course, this is entirely a prediction by the manufacturer. Will the drive be "defective" at that point... no, not necessarily, but it will have been subjected to some wear.... The same can be said of the "Seek_Error_Rate." The worst value encountered so far is "200" and the threshold to fail is 51. I'd say it is doing just fine. Joe L.

The read error rate "VALUE" went down... that is probably a good thing. Although the raw value went up, the "VALUE" is un-changed. RAW_VALUES are used internally by the SMART firmware, no real conclusion can be made here. Ok, you had 26 more high-fly-writes... Temp went up two degrees. Hardware error recovery seems to have improved. At first glance, looks OK to me. I see no compelling reason to RMA it. Joe L.

If you touch a power cable and can hear any disk spin down, it is NOT that it is power sensitive, a disk is losing power. It is doing an emergency head retraction, as it detected the power fluctuation. Yes, each connection introduces a tiny voltage drop, but the resistance of a properly made connection will not affect a disk. It is not enough to just say that you tied the cables down. Those same loose connections will act up over time as they heat and cool, as they vibrate, even microscopically, as the case vibrates when disks are used. The pre-clear script moves the disk heads back and forth across the platters more than most other operations, and probably vibrates them a bit more than simply watching a movie, which would read each cylinder in turn (assuming most are not fragmented) It might have vibrated the case enough to make the poor connection reveal itself. So, to test, stop the array (so no data is being written) then listen for heads un-loading while moving all the power cables slightly. Find and fix the poor connection. It might be a splitter, it might be a connector on the power supply, it could even be a connector on a disk drive... but if you do not fix it, it will come back to haunt you some time when it not convenient... (when another disk really fails, and all of a sudden a single drive failure becomes a multiple drive failure) It might be a poorly built plug on a power supply, with a poor crimp on the wire... or it could be a microscopic crack on the circuit board of a disk drive, where the power connector soldered connection has failed from being stressed too much. In my case it was a "Y" splitter, but it caused me a lot of hair loss... and I have very little to spare these days. I did a bit of math on this in another post: http://lime-technology.com/forum/index.php?topic=3211.msg27129#msg27129 One thing I did not think of is a disk might be in the middle of a pre-clear cycle, all the other disks are sleeping, and then you spin up all the other drives. With a poorly configured arrangement of splitters, or a marginal power supply, the sudden voltage drop on the drive being cleared, caused by the huge current spike of all the other drives spinning up, could cause it to think it is losing power and retract its heads. If you need multiple splitters, and many of us with large arrays do, configure them to use as few as you can. Or, purchase 4-way splitters as I did, with less connectors to have poor connections. I know the splitters are very low-tech, but the originals in my server were not very large gauge wire, and had very light-weight pins compared to the ones I replaced them with. The new 4 way splitters are on the left in the picture below... they are much higher quality construction than the two way splitters I removed from the server on the right. I have a feeling the crimps on the pins of the old splitter's connectors are of poor quality, and intermittent... Search here for what I purchased: http://www.intrex.com/parts/parts.aspx This is the part number: ADA-POWYX2 Very decent for $2.99 each. There are two Intrex stores nearby to me, so it is easy to stop by for parts... Besides, working better, I'm thinking the new splitters will help to prevent "hair loss" Joe L.

... I'm done... I ran the memorytest overnight - it passed 8 times without errors plus I ran the reisefsck on all data drives - all went through without any errors reported. Checked syslog also, no errors, neither after boot nor after all those activities. Anything else I can / should do? So it seems that those problems are all around those 2 drives ? If so, I probably prefer to dispose them and order 2 new ones - much cheaper than the time it took me to check the whole server ... ;-) Other than trying new cables to those two drives, I think you are on the right track. The preclear script showed you their true colors... If they are under warranty, it is a no-brainer for me. (although I'd try a new data cable anyway if you happen to have one first...) Certainly, if you see the errors starting once more, stop the pre-clear (press Control-C to interrupt the process) and get an RMA number or two. Joe L.

The preclear_disk script is very good at thrashing exercising a disk. As already said, it is far easier to RMA the drives before they are loaded with your data if you find they do not test well. The errors you saw could be because of bad SATA cables or bad power cables/splitters, or even a bad disk controller. But... Remember, your SMART report showed an emergency retraction of the heads to a safe landing spot when it thought the drive was losing power in the middle of the preclearing process. That is pretty drastic as it tries to save itself from a head crash. Is your power supply being overloaded? Are you using a backplane for power distribution? Lots to check out, but, at least you are more informed than most Window's OS users. They just blue-screen. Joe L.

Part of the original cache_dirs script set the cache-pressure to 0. I've since learned that value does NOT free up ram when other processes need it. even if you had stopped cache_dirs, the memory Linux allocated for cache would not have been freed. You would need to type something like: sysctl vm.vfs_cache_pressure=10 to allow it to use the memory is had put into cache. (The most recent version of cache_dirs fixed that and uses cache_pressure=5 by default) More memory might help, but 2 Gig should be plenty. Your first priority should be the disk errors. These errors are /dev/sdn ul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: BMDMA2 stat 0xd0009 Jul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: cmd 25/00:00:30:8a:06/00:02:00:00:00/e0 tag 0 dma 262144 in Jul 23 03:34:19 XMS-GMI-01 kernel: res 51/04:7f:b1:8b:06/00:00:00:00:00/f0 Emask 0x1 (device error) Jul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: status: { DRDY ERR } Jul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: error: { ABRT } Jul 23 03:34:19 XMS-GMI-01 kernel: ata12.00: configured for UDMA/100 Jul 23 03:34:19 XMS-GMI-01 kernel: ata12: EH complete Jul 23 03:34:19 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB) Jul 23 03:34:19 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Write Protect is off Jul 23 03:34:19 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Mode Sense: 00 3a 00 00 Jul 23 03:34:19 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: BMDMA2 stat 0xd0009 Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: cmd 25/00:00:30:dc:12/00:02:00:00:00/e0 tag 0 dma 262144 in Jul 23 03:34:32 XMS-GMI-01 kernel: res 51/04:00:2f:de:12/00:00:00:00:00/f0 Emask 0x1 (device error) Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: status: { DRDY ERR } Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: error: { ABRT } Jul 23 03:34:32 XMS-GMI-01 kernel: ata12.00: configured for UDMA/100 Jul 23 03:34:32 XMS-GMI-01 kernel: ata12: EH complete Jul 23 03:34:32 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB) Jul 23 03:34:32 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Write Protect is off Jul 23 03:34:32 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Mode Sense: 00 3a 00 00 Jul 23 03:34:32 XMS-GMI-01 kernel: sd 12:0:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA These are memory allocation errors: Jul 24 01:37:13 XMS-GMI-01 kernel: shfs: page allocation failure. order:0, mode:0x4020 Jul 24 01:37:13 XMS-GMI-01 kernel: Pid: 5060, comm: shfs Not tainted 2.6.29.1-unRAID #2 Jul 24 01:37:13 XMS-GMI-01 kernel: Call Trace: Jul 24 01:37:13 XMS-GMI-01 kernel: [<c0146307>] __alloc_pages_internal+0x33f/0x352 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c015ec2c>] __slab_alloc+0x158/0x42b Jul 24 01:37:13 XMS-GMI-01 kernel: [<c015fce6>] __kmalloc_track_caller+0x75/0xbe Jul 24 01:37:13 XMS-GMI-01 kernel: [<c02d8535>] ? __netdev_alloc_skb+0x17/0x34 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c02d8535>] ? __netdev_alloc_skb+0x17/0x34 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c02d8217>] __alloc_skb+0x4a/0x102 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c02d8535>] __netdev_alloc_skb+0x17/0x34 Jul 24 01:37:13 XMS-GMI-01 kernel: [<f82512fa>] rtl8169_rx_fill+0x91/0x144 [r8169] Jul 24 01:37:13 XMS-GMI-01 kernel: [<f82516cf>] rtl8169_rx_interrupt+0x322/0x379 [r8169] Jul 24 01:37:13 XMS-GMI-01 kernel: [<f825276c>] rtl8169_poll+0x2f/0x124 [r8169] Jul 24 01:37:13 XMS-GMI-01 kernel: [<c02df24c>] net_rx_action+0x5d/0x119 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c0124a48>] __do_softirq+0x84/0x121 Jul 24 01:37:13 XMS-GMI-01 kernel: [<c0124b1a>] do_softirq+0x35/0x3a Jul 24 01:37:13 XMS-GMI-01 kernel: [<c0124d97>] irq_exit+0x38/0x3a Jul 24 01:37:13 XMS-GMI-01 kernel: [<c0104a69>] do_IRQ+0x67/0x7e Jul 24 01:37:13 XMS-GMI-01 kernel: [<c01033a7>] common_interrupt+0x27/0x2c Jul 24 01:37:13 XMS-GMI-01 kernel: Mem-Info: Jul 24 01:37:13 XMS-GMI-01 kernel: DMA per-cpu: Jul 24 01:37:13 XMS-GMI-01 kernel: CPU 0: hi: 0, btch: 1 usd: 0 Jul 24 01:37:13 XMS-GMI-01 kernel: Normal per-cpu: Jul 24 01:37:13 XMS-GMI-01 kernel: CPU 0: hi: 186, btch: 31 usd: 180 Jul 24 01:37:13 XMS-GMI-01 kernel: HighMem per-cpu: Jul 24 01:37:13 XMS-GMI-01 kernel: CPU 0: hi: 186, btch: 31 usd: 136 Jul 24 01:37:13 XMS-GMI-01 kernel: Active_anon:1704 active_file:6958 inactive_anon:1964 Jul 24 01:37:13 XMS-GMI-01 kernel: inactive_file:416907 unevictable:31739 dirty:16436 writeback:1553 unstable:0 Jul 24 01:37:13 XMS-GMI-01 kernel: free:1895 slab:11856 mapped:1835 pagetables:175 bounce:0 Jul 24 01:37:13 XMS-GMI-01 kernel: DMA free:3488kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:8676kB unevictable:0kB present:15852kB pages_scanned:0 all_unreclaimable? no Jul 24 01:37:13 XMS-GMI-01 kernel: lowmem_reserve[]: 0 867 1887 1887 Jul 24 01:37:13 XMS-GMI-01 kernel: Normal free:1320kB min:3732kB low:4664kB high:5596kB active_anon:1888kB inactive_anon:2148kB active_file:16288kB inactive_file:772872kB unevictable:40kB present:887976kB pages_scanned:0 all_unreclaimable? no Jul 24 01:37:13 XMS-GMI-01 kernel: lowmem_reserve[]: 0 0 8158 8158 Jul 24 01:37:13 XMS-GMI-01 kernel: HighMem free:2772kB min:512kB low:1608kB high:2704kB active_anon:4928kB inactive_anon:5708kB active_file:11544kB inactive_file:886080kB unevictable:126916kB present:1044328kB pages_scanned:0 all_unreclaimable? no Jul 24 01:37:13 XMS-GMI-01 kernel: lowmem_reserve[]: 0 0 0 0 Jul 24 01:37:13 XMS-GMI-01 kernel: DMA: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3488kB Jul 24 01:37:13 XMS-GMI-01 kernel: Normal: 134*4kB 2*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1304kB Jul 24 01:37:13 XMS-GMI-01 kernel: HighMem: 23*4kB 13*8kB 15*16kB 33*32kB 8*64kB 2*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2772kB Jul 24 01:37:13 XMS-GMI-01 kernel: 455669 total pagecache pages Jul 24 01:37:13 XMS-GMI-01 kernel: 0 pages in swap cache Jul 24 01:37:13 XMS-GMI-01 kernel: Swap cache stats: add 0, delete 0, find 0/0 Jul 24 01:37:13 XMS-GMI-01 kernel: Free swap = 0kB Jul 24 01:37:13 XMS-GMI-01 kernel: Total swap = 0kB Jul 24 01:37:13 XMS-GMI-01 kernel: 490976 pages RAM Jul 24 01:37:13 XMS-GMI-01 kernel: 263138 pages HighMem Jul 24 01:37:13 XMS-GMI-01 kernel: 5140 pages reserved Jul 24 01:37:13 XMS-GMI-01 kernel: 318096 pages shared Jul 24 01:37:13 XMS-GMI-01 kernel: 170962 pages non-shared Joe L.

You have several drives with errors, not just the one you are trying to clear... and it looks like you are running out of memory too. Are you running any add-on packages? (other than the pre-clear) The user-share file system is constantly reporting it cannot allocate memory. How much RAM are you running? I can't go into detail now... Perhaps RobJ can take a look and provide his input. Perhaps send him a PM and ask him to take a look. Joe L.

This is a new one to me... According to a "google" search on "Power-Off_Retract_Count", I got the following [pre] # Power-Off_Retract_Count = No of times drive was powered off in an emergency, called Emergency Unload. # Load_Cycle_Count = This number is highly affected by your power management policies. For e.g. a too aggressive power management might put hard disk to sleep too often. This number is indicative of when your hard disk parks, unparks , spins up, spins down. [/pre] So. reading between the lines... unless you powered down the disk while it was being cleared, it *thought* it had lost power, or it really did lose power. It retracted the disk heads in an emergency-unload, thinking it had lost power, then loaded them again once it thought power had been restored. I'd check the system log for any other errors while the drive was being cleared. I'd also check any power connectors or "Y" splitters. They can be intermittent. Joe L.

If it stays at 5, in my opinion, no problem. If it increases over time, then you might want to use the RMA process. Odds are good it will stabilize. I have one 250Gig drive that has had 100 relocated sectors since the first time I ran smartctl on it. That number has never changed on that disk. I'd say, download the new version of preclear_disk.sh and run another set of test cycles and see if it shows an increase in re-allocated sectors. (the new version stress-tests the drive more. The old one had a bug that prevented the random cylinders from being read in addition to the linear read that was properly occurring) If the number stays at 5, fine, if not another test cycle might be in order. At that point you have all the evidence you need if an RMA is warranted. You might want to start a thread with your preclear experience. It will allow the questions about the output to all be in one spot. Joe L. Ok.. I ran one more full cycle with the new verions of the script and I got no reallocated sector changes. Should I run once more or do you think I'm good now and can put the disk into service? So... first 3 cycles. - 5 reallocated sectors 4th cycle - no more reallocated sectors. Jim If you need the space, and need it now, go ahead and assign it to the array. If not in a real rush, let it run another cycle or two, or overnight. Remember, you did 3 cycles to identify the first 5 sectors... you do not know if they all showed up in the the first cycle, or the third. It is good that no more bad sectors were identified. Glad it is working for you. How long did it take to run a cycle on the 1TB drive in your server? Joe L.

Hi, I modified the script to check if there is any htpc left running and this works fine. I inserted commands in the go script - this blocks my console. So: How do I "background" it ("launch as separate script in background"?) to keep my console free? Sorry for the silly question, but I am completely unexperienced with shell scripts... tnx, Guzzi nohup your_script_name & nohup allows it to keep running after you log off the console, the "&" puts it in the background. As an alternative, you can do this: cd folder_that_has_your_script echo "your_script_name" | at now + 1 minute Joe L.

Unless you spin down the drives, they will not spin down on their own unless they have been idle for whatever time-out you configured. I don't see there being much of an issue with disks spinning down and the server shutting down un-unexpectedly when you are using it unless you press the spin-down button.

Great that it is working with s3 suspend mode.. Did you ever tell us what motherboard you are using? (Others might want to know one that has proven to work with s3 mode) Your script will work. Drop a copy of it in the /etc/cron.hourly folder and your server will go to s3 suspend mode within an hour of the drives all going to sleep. You can put your script on the flash drive and then put a line in the "config/go" script to copy it to /etc/cron.hourly folder every time you reboot. Or, invoke it with your own entry to the crontab if you want it to be checked more frequently. Joe L.

You can kill the smbd process that has the file locked Log in via telnet, type: smbstatus It will type a listing of the locked files, looking similar to the listing below: Samba version 3.0.28a PID Username Group Machine ------------------------------------------------------------------- 2549 joe joe dell630 (192.168.2.10) Service pid machine Connected at ------------------------------------------------------- flash 2549 dell630 Tue Oct 7 22:54:23 2008 Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 2549 0 DENY_NONE 0x100001 RDONLY NONE /boot . Tue Oct 7 22:55:43 2008 The "pid" of the smbd process holding the locked file is given in the output. In my case, /boot is locked by process ID 2549. I can then type ps -ef | grep smbd to see what process is holding the lock. (It will be an smbd process) ps -ef | grep smbd root 1790 1 0 Oct01 ? 00:00:01 /usr/sbin/smbd -D root 1791 1790 0 Oct01 ? 00:00:00 /usr/sbin/smbd -D root 2549 1790 0 Oct07 ? 00:03:19 /usr/sbin/smbd -D root 20032 22786 0 23:26 pts/1 00:00:00 grep smbd Lastly, you can kill the process holding the lock. Type (using your process ID) kill 2549 Here is what happened when I did that on my server [pre] root@Tower:/boot# kill 2549 root@Tower:/boot# smbstatus Samba version 3.0.28a PID Username Group Machine ------------------------------------------------------------------- Service pid machine Connected at ------------------------------------------------------- No locked files [/pre] The lock is gone... Have fun... Joe L.

I realize that most people today are putting together SATA based arrays, but mine is an original IDE based MD1200 in a Coolermaster Stacker case. I can't even take credit for the wiring. Tom at Lime-Technology pimped out my server when I purchased it from him in October 2005. It is fully cabled with flat IDE cables to the 12 Cremax MB123AK drive trays. It has an Intel D865GLCLK motherboard, 2.26GHz Celeron, and 512MB of RAM. I was very impressed with the way the cables were neatly arranged. I've seen PC's with only a few drives not look anywhere near as neat. Joe L.