Guzzi

To give you at least a sample value: My server pulls 2.4 Watts when in S3 mode. Much less than online with drives spun down, but of course more, than when disconnected from the powersocket ;-)

Thanks, did some reading, but I think I will not start building my own circuits - any suggestion for something available to buy? The optimum would be a fancontroller, that can be controlled via the script and has enough power to drive 6 fans in parallel. RPMs could be taken from the MoBo, but it should somehow be accessible via .../hostx/pwmy, right?

Thanks for the quick replay, BubbaQ. Hmmm, any hint on such a power circuit - maybe a "proven one"? I could imagine it would be easy to to that for "true 4-pin-fans" - just take the 12V (pins 1&2) from the powersupply directly and provide pwm signal (pin4) to all fans - the current then would be supplied by the powersupply instead of the fanheader ... but this doestn't work on my pwm2, that uses pwm on pin2 and thus has to provide the full load. Would it be possible to use that pin2 signal for pin4 signaling and the 12V from atx directly when using "true 4-pin-fans" - or are the signals different?

I have the following situation: PWM works on 2 headers - PWM1 (used already by CPU with 4pin, thus 12V and pwm on Pin4) and PWM2 - that is available, but uses PWM on Pin2 - Pin4 is unused. In general, it works fine to control a "classic" fan on PWM2 (a true 4-pin-pwm-fan doestn't work of course) with a script controlled by the HD temperature. My question is: I would like to control all my HD-fans with this script. They are currently connected to 7V - which is too low for a paritycheck and too high if the drives are spun down. Obviously I should not connect all 6 fans to a single header - so my question is: Is there a solution to drive 6 fans by a script via PWM2, assuming all fans are the same brand and I use the speedpin just from one of them? Thanks in advance, Guzzi Script

4.5.5 added support for 21 drives. The main issue with 24 drives is that I can't test it. How do you count the drives? We have today support for "21 drives" (19 + parity + cachedisk) - so when you're talking about 21 drives you mean 21 datadrives + parity (thus adding 2 more drives)? This would just allow me to add my 2 new drives... Back to topic: In case I would want to test your new version, I should remove the jumper - and should I also redo the preclear? I assume "yes", because currently there should be 1 sector uncleared, because the preclear with jumper set added 1 sector, right?

Hi Tom, I just received 2 2TB EARS Drives and did "best practice" after reading here - this is: setting jumper 7-8 on the drives and did a preclear with JoeL.'s script. To be more exact: The drives are the newer drives with only 3-platter. The drives are planned to replace older 300GB drives - but after reading your last post I am unsure what to do - my plan was to use those "jumpered, precleared" drives to replace older drives and let them rebuild. So what would be the official recommendation now? Thanks, Guzzi PS: Any plans, when 24 drive support will be included? In this case I would add instead of replace those drives...

No, you can't pause - you only can cancel and restart later. btw. imho 40 C is nothing to worry about, it's absolutely inside the specs.

+1 ! I also stumbled over this in the past - at least a flyover or help/description should be made available ...

Hi Joe L. i ran Reiserfschk and it recommends to do a rebuid-tree. I will wait before doing so for your feedback. btw, I have stopped the parity sync right after reboot, so it has shown 270 sync errors, but did not yet complete (so there is now only some sync done on root of the drive, but not the rest, thus parity for now is more or less useless for this array, right? Should I replace the drive with a new one, run parity and try to save as much data from the current md11 drive as possible? (Just asking, because to my understanding I currently don't have a protected array anyway .... and I would get rid of the drive from the array...) root@XMS-GMI-02:~# reiserfsck --check /dev/md16 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md16 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Tue Apr 20 08:23:35 2010 ########### Replaying journal.. Reiserfs journal '/dev/md16' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 3)/ 3 (of 170)/114 (of 170)block 81835406: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (81835406), whole subtree is skipped / 4 (of 170)/ 1 (of 170)block 81893123: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (81893123), whole subtree is skipped / 39 (of 170)/ 56 (of 170)block 88049724: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (88049724), whole subtree is skipped / 2 (of 3)/ 59 (of 86)/ 2 (of 170)block 120818206: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (120818206), whole subtree is skipped / 3 (of 3)/ 80 (of 148)/100 (of 165)block 163348502: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (163348502), whole subtree is skipped / 83 (of 148)/132 (of 170)block 180782520: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (180782520), whole subtree is skipped / 84 (of 148)/ 21 (of 170)block 24707073: The level of the node (0) is not correct, (1) expected the problem in the internal node occured (24707073), whole subtree is skipped finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 7 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Tue Apr 20 08:36:25 2010 ########### root@XMS-GMI-02:~#

Hi Joe L., it is obvious, that there is filesystemcorruption - but the questions is, what caused this - and since there are some messages in the syslog posted that seem to indicate problems with the communication to the drive, I am not sure, if it is really a good idea to let the fs-check run in this state. The thing, that I do not understand is: how can there be filesystemcorruption, when there is not a single error reported by unraid - neither regarding parity, nor regarding any drive? So istn't this something the the parity should heve either covered or at least notified (datacorruption on a drive)? Errors on the unRAID interface are "read" errors. The errors in the syslog are several layers lower than the "md" driver. The "md" driver just uses the reiserfs under it. So for my understanding: When I write data to the box, I cannot know, if it was written properly unless I verified it myself manually be reading and comparing to source? So it's only the parity drive, that will "read" during write operations and thus check, if it can read properly? Not such a big problem, because the box was stable for a year and all was fine, there were never errors in the syslog (I checked from time to time). The only change was the addition of this precleared disk (even the controller and powercables already had been prepared a year ago for extensions). That narrows it down to - powersupply (because of additional disk): Dont think so, because the errors were only on this one disk - controller: its Sil3114, had been in the box for a year, but this is the forst disk connected to it, so it might be faulty - cable of this specific disk - the disk itself If you check the preclear result of the disk some posts above, I noted, that there were some errors in syslog before, when precleared in my unraid testbox Just wanted to do that, the box did hang, no telnet, no console, no webinterface (neither 80 nor 8080), console just telling about filesystemcorruption, no more reaction an keystrokes :-( As mentioned above, that should be fine, done long time ago and never had problems with the box until this disk was added Well, I will have to to a hard poweroff to get access again - or any other way to get it back to live? Ping still works, so the IP-Stack is alive... Edit: ok, I switched off the box and restarted. It happened, what i didn't want to happen - paritysync started and reported 270 syncerrors - I assume, that parity was updated, but I trusted my parity drive and assume, the errors were on the new harddisk. So I assume, there is no more way to try starting without the "bad new disk" and use the proper data from the rest of the array - because now it's "bad" too and replicated the errors from the drive to parity, right? S....t :-( Now Smartreport and syslog added ... syslog-2010-04-20.txt SmartReport.txt

Hi Joe L., it is obvious, that there is filesystemcorruption - but the questions is, what caused this - and since there are some messages in the syslog posted that seem to indicate problems with the communication to the drive, I am not sure, if it is really a good idea to let the fs-check run in this state. The thing, that I do not understand is: how can there be filesystemcorruption, when there is not a single error reported by unraid - neither regarding parity, nor regarding any drive? So istn't this something the the parity should heve either covered or at least notified (datacorruption on a drive)?

Ok, so I installed the drive and added to the array, copied data onto it, all without "obvious" errors - but since yesterday I can't copy anymore and get reiserfs-related errors. Even reading brings entries like this: Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS (device md16): Remounting filesystem read-only Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: BMDMA2 stat 0x80d0009 Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: failed command: READ DMA EXT Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: cmd 25/00:00:17:71:ed/00:04:64:00:00/e0 tag 0 dma 524288 in Apr 5 18:14:09 XMS-GMI-02 kernel: res 51/04:3f:d8:72:ed/00:02:64:00:00/e0 Emask 0x1 (device error) Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: status: { DRDY ERR } Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: error: { ABRT } Apr 5 18:14:10 XMS-GMI-02 kernel: ata11.00: configured for UDMA/100 Apr 5 18:14:10 XMS-GMI-02 kernel: ata11: EH complete Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: BMDMA2 stat 0x80d0009 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: failed command: READ DMA EXT Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: cmd 25/00:a0:47:60:59/00:02:04:00:00/e0 tag 0 dma 344064 in Apr 5 18:14:27 XMS-GMI-02 kernel: res 51/04:bf:28:62:59/00:00:04:00:00/e0 Emask 0x1 (device error) Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: status: { DRDY ERR } Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: error: { ABRT } Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: configured for UDMA/100 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11: EH complete No parity errors shown and all drive errors in main page show "0" What should I do? Is the data lost? Should I remove the drive to get the data via the rest of the drives + parity? Sorry to bring this up again, but my box is sitting since to weeks in the corner and I hoped to get some good advices what to do best... If there is no comment, I will remove the drive and see, if this makes the situation better and do reiserfck on the drive and see, what happens ...

Ok, so I installed the drive and added to the array, copied data onto it, all without "obvious" errors - but since yesterday I can't copy anymore and get reiserfs-related errors. Even reading brings entries like this: Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS (device md16): Remounting filesystem read-only Apr 5 18:13:22 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one 1 Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-5150 search_by_key: invalid format found in block 163348502. Fsck? Apr 5 18:13:56 XMS-GMI-02 kernel: REISERFS error (device md16): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [87 608 0x0 SD] Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: BMDMA2 stat 0x80d0009 Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: failed command: READ DMA EXT Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: cmd 25/00:00:17:71:ed/00:04:64:00:00/e0 tag 0 dma 524288 in Apr 5 18:14:09 XMS-GMI-02 kernel: res 51/04:3f:d8:72:ed/00:02:64:00:00/e0 Emask 0x1 (device error) Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: status: { DRDY ERR } Apr 5 18:14:09 XMS-GMI-02 kernel: ata11.00: error: { ABRT } Apr 5 18:14:10 XMS-GMI-02 kernel: ata11.00: configured for UDMA/100 Apr 5 18:14:10 XMS-GMI-02 kernel: ata11: EH complete Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: BMDMA2 stat 0x80d0009 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: failed command: READ DMA EXT Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: cmd 25/00:a0:47:60:59/00:02:04:00:00/e0 tag 0 dma 344064 in Apr 5 18:14:27 XMS-GMI-02 kernel: res 51/04:bf:28:62:59/00:00:04:00:00/e0 Emask 0x1 (device error) Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: status: { DRDY ERR } Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: error: { ABRT } Apr 5 18:14:27 XMS-GMI-02 kernel: ata11.00: configured for UDMA/100 Apr 5 18:14:27 XMS-GMI-02 kernel: ata11: EH complete No parity errors shown and all drive errors in main page show "0" What should I do? Is the data lost? Should I remove the drive to get the data via the rest of the drives + parity?

I had a setup with pro license and 21 drives (500 and 300 GBs) - there is no difference technically in running 2TB drives instead - green drives even need less power than former 7200 rpm drives. The important thing is to have good powersupply, good cables for powersupply of the drives (!!) and good sata cables

Hi Joe L., thnks for the feedback - preclear now has finished and this is final smart differences reported. I have attached syslog also, because there are smarterrors reported and post would become too long (there is 2 harddrives in syslog, cause I was running 2 preclears at the same time, one is a brandnew disk (sda), one is an older one (sdb) to reuse where I get those problems). ============================================================================ == == Disk /dev/sdb has been successfully precleared == ============================================================================ 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 58c58 < 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x000e 100 253 051 Old_age Always - 0 65c65 < 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 1 --- > 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 71c71 < ATA Error Count: 156 (device log contains only the most recent five errors) --- > ATA Error Count: 174 (device log contains only the most recent five errors) 86c86 < Error 156 occurred at disk power-on lifetime: 7415 hours (308 days + 23 hours) --- > Error 174 occurred at disk power-on lifetime: 7416 hours (309 days + 0 hours) 97,101c97,101 So it seems the relocation was done - but I am worried about all those ata errors in syslog - I don't have any of those with "healthy" harddisks. What would you recommend? Running another preclear and see, if it's better now? Thanks for your help, Guzzi syslog-2010-03-24.txt

Hi, I am currently trying to preclear a frive I used formerly in windows, but get errors: Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: SMART Attributes Data Structure revision number: 16 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: Vendor Specific SMART Attributes with Thresholds: Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 1 Raw_Read_Error_Rate 0x000f 200 199 051 Pre-fail Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 3 Spin_Up_Time 0x0003 182 178 021 Pre-fail Always - 7866 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 874 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 7416 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 11 Calibration_Retry_Count 0x0012 100 253 051 Old_age Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 90 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 49 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 193 Load_Cycle_Count 0x0032 188 188 000 Old_age Always - 36071 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 1 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 1 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 7708 Mar 24 00:34:14 XMS-GMI-03 preclear_disk-start[4187]: 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0 and lots of things like this: Mar 24 00:34:39 XMS-GMI-03 kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Mar 24 00:34:39 XMS-GMI-03 kernel: 00 00 52 0d Mar 24 00:34:39 XMS-GMI-03 kernel: sd 5:0:0:0: [sdb] ASC=0x11 ASCQ=0x4 Mar 24 00:34:39 XMS-GMI-03 kernel: sd 5:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 52 00 00 02 00 00 Mar 24 00:34:39 XMS-GMI-03 kernel: end_request: I/O error, dev sdb, sector 21005 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2625 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2626 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2627 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2628 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2629 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2630 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2631 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2632 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2633 Mar 24 00:34:39 XMS-GMI-03 kernel: Buffer I/O error on device sdb, logical block 2634 Mar 24 00:34:39 XMS-GMI-03 kernel: ata5: EH complete Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0 Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: irq_stat 0x40000008 Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: failed command: READ FPDMA QUEUED Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: cmd 60/08:18:08:52:00/00:00:00:00:00/40 tag 3 ncq 4096 in Mar 24 00:34:43 XMS-GMI-03 kernel: res 41/40:00:0d:52:00/6d:00:00:00:00/40 Emask 0x409 (media error) Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: status: { DRDY ERR } Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: error: { UNC } Mar 24 00:34:43 XMS-GMI-03 kernel: ata5.00: configured for UDMA/133 Mar 24 00:34:43 XMS-GMI-03 kernel: ata5: EH complete Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0 Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: irq_stat 0x40000008 Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: failed command: READ FPDMA QUEUED Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: cmd 60/08:00:08:52:00/00:00:00:00:00/40 tag 0 ncq 4096 in Mar 24 00:34:47 XMS-GMI-03 kernel: res 41/40:00:0d:52:00/6d:00:00:00:00/40 Emask 0x409 (media error) Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: status: { DRDY ERR } Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: error: { UNC } Mar 24 00:34:47 XMS-GMI-03 kernel: ata5.00: configured for UDMA/133 Mar 24 00:34:47 XMS-GMI-03 kernel: ata5: EH complete Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0 Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: irq_stat 0x40000008 Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: failed command: READ FPDMA QUEUED Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: cmd 60/08:18:08:52:00/00:00:00:00:00/40 tag 3 ncq 4096 in Mar 24 00:34:51 XMS-GMI-03 kernel: res 41/40:00:0d:52:00/6d:00:00:00:00/40 Emask 0x409 (media error) Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: status: { DRDY ERR } Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: error: { UNC } Mar 24 00:34:51 XMS-GMI-03 kernel: ata5.00: configured for UDMA/133 Mar 24 00:34:51 XMS-GMI-03 kernel: ata5: EH complete There is also pending relocation shown for 1 sector. The UDMA errors probably are from the past where either the cable was bad or the powersupply weak - it should be no problem for further use, right? Does it make sense to "factoryformat" the drive and give it another try or should the drive not be used anymore? Can I send the drive back to the manufacturerer and will I get replacement or are those errors not giving that possibility? Thanks, Guzzi

My server takes approx 2,5 Watts when in S3, so yes, RAM refresh is required but doesn't need very much. If you loose power, you cannot resume as you stated, it's like disconnecting while the system is running. you should use a UPS anyway ... Might be worth to call a "sync" before going to S3 - I have never done this so far.

@BubbaQ: I am aware of all 3 points - the cascading fans already take care about only reading the speed on the 1st. @JoeL.: Thanks, don't yet understand all details, but will try to play with that a bit...

afaik there are pwm fans that can be cascaded - it's only limited by the current the mb can supply on the pwm header. so depending on the fans, you can use several fans on one header and control them via a script - that's the way I plan to do...

... sounds interesting - I have it87 too - so I understand, I could easily control the (HD)fans via those pwm commands in a script (when HD fans are connected to a header that supports that)? How do I get the HD temperatures via script? I have WD drives, that support temperature reading while spin down afaik.

The way I would do it: Create a new Usershare "music" map yourself a drive to the root of usershares (via smb-extra.conf, e.g. TOWER-root with path=/mnt/user). You will have all your usershares then on 1 driveletter/SMB-share available! via a proper tool (i use FC on windows so SMB share, as mentioned above) move the stuff as you wish - you can move files/directories between different usershares - the usersharesystem will update and recognize all nicely. No filed would be physically moved, just directoryinfos updated - thus all your files stay there where you have them today. done ;-) good luck, and of coure "no warranty", as I don't know if this approach is officially supported by UnRaid ;-)

I had to go via the downloadpage - maybe problem was caused by proxy (got 500 error). Package works fine, Thanks!

Weebotechs package can be installed, I can run iftop, but it terminates after soe seconds with "segmentation fault" JoeLs Link is dead for me. All this tried on 4.5.0 Syslogentry: Feb 17 13:09:33 TOWER kernel: iftop[11200]: segfault at 0 ip (null) sp b6d54ae8 error 14 in iftop[8048000+ed000]

Hmmm, I remember theat I have read this post in the past - but didn't try because of the warnings. Currently have no testsystem to give it a try on not in use environment ... Googling showed up posts that people were not able to set back drive to original state (WD-drives, as I do have them). So before giving this a try I would be interested in experiences of other user and better understanding of what it means. - hdparm -s sets the POIS mode of the drive - On cold startup this causes a very long delay (approx 15 sec per drive = 300 secs for 20 drives = 5 mins !? - It seems, 3132 is supporting this - no info found if also drives via portmultiplier word (i assume yes) ; found no infos about drives connected to SB700 southbridge as well - On WOL (wake-up from S3 mode) the consequence would be, that the drive would NOT spin up (and immediately fall asleep), but just switched online controllerwise without spinning - right? - If the drive is accessed by UnRaid, the drive will spinup as usual Can anyone confirm or correct me - and also feedback to user experiences are welcome.

How to you do that? My WD-Greens spin up when server wakes up via WOL and after "reinitilization" - some seconds later - spin down again. Can you point me to some info regarding those jumpers to avoid spinup after WOL? I thought this is required for reinitialization of the drive. And I also have several resets after WOL to reinitialize the interfaces, e.g.: Feb 11 22:18:28 XMS-GMI-01 kernel: ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Feb 11 22:18:28 XMS-GMI-01 kernel: ata3.00: failed to IDENTIFY (I/O error, err_mask=0x11) Feb 11 22:18:28 XMS-GMI-01 kernel: ata3.00: revalidation failed (errno=-5) Feb 11 22:18:28 XMS-GMI-01 kernel: ata3.15: hard resetting link Feb 11 22:18:28 XMS-GMI-01 kernel: ata3: controller in dubious state, performing PORT_RST Thnaks, Guzzi