the_moose

Joe L. Many thanks for getting back to my post. The results to this issue are. I swapped the 2 drives on the suspected bad SATA card one by one to one of the spare cards, enabling me to correctly assign the device. it would seem that it was indeed a failed SATA PCI card. This is now removed and am parity checking without the error messages as we speak. Again thanks for getting back to me. Cheers Matt

sorry i wrote this early in the morning. i meant will it be ok if a use a different sata port for the drives. Thanks Matt

Hi I have developed a problem with my server. It has started to spit out the below in the syslog extract, although I can still access the shares fine. This happened during a parity check I ran (no correct option). Does this look like a SATA card issue. I have disk 1 and disk 2 on the same PCI SATA Card - and it would seem the problem below is related to ata1 and ata2. I have a 700W power supply. I have made no changes to the hardware configuration for a long time. This may seem like a stupid question but - if I swap out the sata card for a new one is unRAID locked to it in any way i.e. is the drive assignment only locked to the physical disk ID itself and it will not notice a new a new sata card. I'm pretty sure this is a case, but just checking. Thanks Matt Jun 2 04:01:36 Tower logger: mover finished Jun 2 04:01:48 Tower kernel: ata1: drained 32768 bytes to clear DRQ. Jun 2 04:01:48 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Jun 2 04:01:48 Tower kernel: ata1.00: failed command: READ DMA EXT Jun 2 04:01:48 Tower kernel: ata1.00: cmd 25/00:00:77:ae:12/00:04:22:00:00/e0 tag 0 dma 524288 in Jun 2 04:01:48 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation) Jun 2 04:01:48 Tower kernel: ata1.00: status: { Busy } Jun 2 04:01:48 Tower kernel: ata1.00: error: { ICRC UNC IDNF ABRT } Jun 2 04:01:48 Tower kernel: ata1: hard resetting link Jun 2 04:01:48 Tower kernel: ata2: drained 32768 bytes to clear DRQ. Jun 2 04:01:48 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Jun 2 04:01:48 Tower kernel: ata2.00: failed command: READ DMA EXT Jun 2 04:01:48 Tower kernel: ata2.00: cmd 25/00:00:77:ae:12/00:04:22:00:00/e0 tag 0 dma 524288 in Jun 2 04:01:48 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation) Jun 2 04:01:48 Tower kernel: ata2.00: status: { Busy } Jun 2 04:01:48 Tower kernel: ata2.00: error: { ICRC UNC IDNF ABRT } Jun 2 04:01:48 Tower kernel: ata2: hard resetting link Jun 2 04:01:49 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jun 2 04:01:49 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jun 2 04:01:49 Tower kernel: ata1.00: configured for UDMA/33 Jun 2 04:01:49 Tower kernel: ata1: EH complete Jun 2 04:01:49 Tower kernel: ata2.00: configured for UDMA/33 Jun 2 04:01:49 Tower kernel: ata2: EH complete Jun 2 04:04:12 Tower kernel: ata1: drained 32768 bytes to clear DRQ. Jun 2 04:04:12 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Jun 2 04:04:12 Tower kernel: ata1.00: failed command: READ DMA EXT Jun 2 04:04:12 Tower kernel: ata1.00: cmd 25/00:00:4f:f8:78/00:04:22:00:00/e0 tag 0 dma 524288 in Jun 2 04:04:12 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation) Jun 2 04:04:12 Tower kernel: ata1.00: status: { Busy } Jun 2 04:04:12 Tower kernel: ata1.00: error: { ICRC UNC IDNF ABRT } Jun 2 04:04:12 Tower kernel: ata1: hard resetting link Jun 2 04:04:13 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

It was remiss of me to ignore that. The problem was that memtest was not in fact launching at all. I have an ASUS motherboard, as such after a little more investigation, I needed to disable USB Mouse support (have kept this off for the time being) in the BIOS (but kept USB Keyboard & Legacy Support enabled - otherwise I cannot boot from the flash) Anyway the memtest has run through several times with no errors and 100% pass, so I guess that all is well with the memory.

Ok so I am back up and running with minimal damage rebooted. Tried running memtest - this wouldnt even kick off, just seemed to hang on the start screen (problem for another day) Booted back into unraid. Sure enough my md3 disk appeared unformatted. So i tried --rebuild-tree again, this time it ran through fine and repaired the bad blocks. Retrieved some lost files in lost+found share. So reiserfsck wouldn't run without falling over with segmentation fault until I rebooted Thanks for all the help, panic over. I think I may set my cache drive up on my music share, so tagging goes there first rather than directly to the parity, as this caused the whole problem in the first place.

Thanks for the re-assurance, and your help, it is very much appreciated. The array is stopped and all drives unmounted at present so parity check is not running. I was concerned as my current parity was successful and very recent therefore I did not want it kicking off again now I have messed up the reiserfsck tree build. I had an issue that was caused by my music software locking whilst tagging some updates (after my last parity check, hence my hope that it is a useful fall back). This caused problems on my md4 and md3 drives. I ran --check and it suggested a --rebuild-tree for md4. this successfully rebuilt, but has a lot less data. The --check also suggested --rebuild-tree for md3 - its the md3 drive that is causing the problems, with --rebuild-tree failing. I am away with work now, but will be tackling this when i return tomorrow and will run memory test, and post a syslog I have all the usual add-ons, so will disable these in the go script before my reboot.

Just reading your advice a few times more. If I could get back to the state I was in before I started these re-builds I would be a happy man. I am concenred I have lost all my data now. The last parity calculation may have some bad areas, but it was mounting fine in read-only, and would allow me to retrieve some of my files. I am unsure how to run on the raw device. Again I would be fine with some lost data and extremly happy to be running a parity check again, with the bulk of my data present! As you can see I am pretty nervous about this one. Many thanks for your advice so far.

I just tried fix-fixable and it fails as follows: root@Tower:~# reiserfsck --fix-fixable /dev/md3 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 check consistency of the filesystem on /dev/md3 and will fix what can be fixed without --rebuild-tree 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 --fix-fixable started at Mon Apr 12 21:16:02 2010 ########### Replaying journal.. Reiserfs journal '/dev/md3' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted root@Tower:~#

Yes it did. No I havent - I will try this No - I can try this. I assume this is the one offered at the boot screen. Is it ok to reboot the server and pick up from where I left off, or will unraid try and strat the parity or soemthing that may make things worse? This disk is pretty much full up Oh dear!

I should have mentioned I am running 4.5.3

Hello I really hope somebody can help me. I am trying to --rebuild-tree one one of my disks using reiserfsck and it crashes out at around 20% eevry time, with a segmentation fault. My last parity check was about a day ago, so should be valid, if I need to rebuild. The stdout is as follows: root@Tower:~# reiserfsck --rebuild-tree /dev/md3 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** 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 rebuild the filesystem (/dev/md3) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. Reiserfs journal '/dev/md3' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Mon Apr 12 19:19:16 2010 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 122274929 blocks marked used Skipping 15663 blocks (super block, journal, bitmaps) 122259266 blocks will be r ead 0%....20%... left 79301556, 1 left 69970736, 12793 /secc Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: ------------[ cut here ]------------ Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: invalid opcode: 0000 [#3] SMP Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:08.0/0000:01:07.0 /host3/target3:0:0/3:0:0:0/block/sdc/removable Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: Process reiserfsck (pid: 459, ti=d8f32000 task=f6b20dc0 task.ti=d8 f32000) Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: Stack: Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: Call Trace: Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: Code: 8d 44 07 30 89 45 dc 39 18 74 05 42 39 ca 7c ea 83 7d dc 00 75 04 0f 0b eb fe 8d 47 28 e8 73 3e 01 c9 8b 45 dc 83 78 0c 00 74 04 <0f> 0b eb fe 8b 55 dc 83 7a 10 00 74 04 0f 0b eb fe 83 7d c8 00 Message from syslogd@Tower at Mon Apr 12 20:27:23 2010 ... Tower kernel: EIP: [<f8288c74>] unraid_make_request+0x1d4/0x342 [md_mod] SS:ESP 0068:d8f33c4c Segmentation fault root@Tower:~#

If it helps I ended up running as root, as user "mysql" had insufficient privileges, despite issuing the chown for it. Works fine now. Just replace "mysql" user with "root". I was advised elsewhere that this is not a problem as unraid runs eevrything as root anyway.

Thanks for the response. Thats good - just checking (still learning ins and outs of linux) I'll leave it as is.

Hello, Looking for some advice. I have been installing various add-ons and generally playing around and come across a consitent problem for me (which will be my lack of understanding) If i want to run something under a user other than root, how do i give permissions to modify directories under /mnt/disk1/... Or should I even be doing this? An example is the MySQL installation So I have ended up running a successfuly MySQl instance, however using "root" instead of "mysql" user due to permission problems (not good!?) i.e. mysql user could not creatre/write files on /mnt/disk1/mysql Even though I have chown the direct directory with for mysql it still has no permissions Is there another recommended disk location I should be using for persisting data away from the shares? Any advice gratefully received

Hello, I am looking to re-order my shares and basically want to introduce an additional top level shares, as follows As-is /Music-A/... /Music-B/... To-be /Music/Music-A/... /Music-B/... So really I am introcuing "Music" as the top level share and moving existin "Music-A" and Music-B" shares beneath. This will enable me to us mt-daap to serve up both my wife's music collection and my own whilst still keeping them seperate on disk (importnant!! ) Is there any way I can achieve this without large amounts of copying? Thanks Matt

Just to confirm I tried the suggested smb config fix I also rebooted the server after applying this. I am afraid to say however this did not fix the issue. Thanks Matt

This is normal, I think its just as the drives are remounted etc on startup. Just make sure your parity check is up to date and regular.

Thanks for the response purko, I will try adding this next time I reboot. As VampyreGTX says, there are no apparant negative effects aside from a very large and growing syslog file I will post back when I have done this.

Hi Wonder if anybody can help, it seems this error has been reported elsewhere in the forums but in a different context. Everything is running fine, however I get this message systematically put out to the syslog, whenever I am running iTunes (with db stored on server), so I assume iTunes is trying to write to the disk in the background and failing for some reason. General copying around and usage does not invoke the error. Syslog is clear except for the below. Any ideas? Thanks Matt ----------CUT------------------ Jan 14 11:25:04 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/iTunes Library.xml (95) Operation not supported Jan 14 11:25:04 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/Temp File.tmp (95) Operation not supported Jan 14 11:26:53 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/iTunes Library.itl (95) Operation not supported Jan 14 11:26:53 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/Temp File.tmp (95) Operation not supported Jan 14 11:26:57 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/iTunes Library.xml (95) Operation not supported Jan 14 11:26:57 Tower shfs: shfs_setxattr: setxattr: /mnt/disk3/iTunes-m/Temp File.tmp (95) Operation not supported

Thanks Joe - really appreciate the quick reply, I can get this underway now. Always best to check in these situations. Serves me right for gamlbing on an old drive, the others are all new. Thanks again Matt

Hi, Appreciate confirmation of the following before I actually do it. I added a new (old) drive yesterday that I had lying around. It basically failed this morning, so I want to simple remove it and carry on whithout it. If I understand correctly I can do the following 1 - Stop the array 2 - Unassigned the faulty disk 3 - Click restore button And the array will re-initialise with remaining disk and most importantly keep all my data! I have no data on the new drive and have no desire to replace it yet as I have load sof space. I just need to confirm that the restore data will not impact my existing data on the good disk. The last parity check was run yesterday morning (probably irrelevant) Thanks Matt

I have just had a very similar problem. I solved it by reseting the CMOS to defaults. I then had more failures in the form of checksum errors on the BIOS boot screen Turned out this was the MB battery. I replaced this and evrything started to behave more stable again. Stuck with the BIOS defaults and only a few changes (MB is years old so havent a clue what I had changed over the years). All ok so far, maybe this helps somebody else