dangil

Hi everyone I am running stock 5.0.5 without any plugins, on 9 HDs (mixed 2tb, 1.5tb and 1tb) during a parity check, I found it odd that the reported number of reads for each HD vary wildly between HDs of the same size one 1TB HD had 10x more reads than the other. 100gb free on one, 70gb free on the other I imagine larger HDs must have more reads on a parity check, but same sized HDs should have the same number of reads right? all HDs are seagate, but their models vary both 1tb are attached to the same sas 1068-e controller can anyone explain this behavior?

anyone else from Brazil?

Hello everyone My X8SIL-V is running bios version 1.0c There is a newer 1.2a bios but I can't find a changelog or list of fixed issues anyone know what's changed between those versions? is it worth the upgrade? I am having no issues whatsoever with my server, but I like to keep things updated

Tom, perhaps you could build the other modules from this driver, from the kernel source itself like mptctl.ko so we can use lsiutil to monitor the board thanks

I see.. thanks for the answer Tom I will try to motivate myself to create a package for this driver

LSI provides an updated DKMS based, mptsas driver source (http://www.lsi.com/products/storagecomponents/Pages/LSISAS1068E.aspx) current unraid version is 3.04.20 latest LSI version in the 3.x series is 3.28.00 latest LSI version in the 4.x series is 4.28.00 I don't know how hard is it to build these and what benefits could be gained with an updated driver. but I think a LSI provided driver is better than a generic one also, how hard would it be to build a addon with this kernel module to be installed upon boot time, without having to involve a new unraid release?

so far so good no crashes with rc4 clean install, no plugins or mods as always if it happens again I will report

thanks Tom! updating to rc-4 to try this fix. will report back

an update since I started unmounting disk6 (connected to the PCI-E Sata Controller) manually, everything is running smoothly. no more crashes I can press stop, unraid will unmount the disks connected to the onboard sata, and stop the array

currently using 5.0-RC3 I am more interested in understanding when the array will or won't autostart, based on the setting, and based on different events that might happen with the array in parallel, I've seen events when the array started automatically, but the setting was NO, so I was wandering if there is any known bugs. if not, I will do more testing

What is the intended behavior of this setting besides starting up the array automatically upon boot ? is there any circunstance when this setting will revert back to NO ? or is there any circunstance when the array will start even if this setting is set to NO ? or vice-versa, the array wont't start even if it is set to YES ? is there a bug that displays the wrong info on this setting ?

Since beta6a, until rc3, I have a intermittent issue while stopping the array. umount crashes the server when stopping the array I have a Supermicro X8SIL-V motherboard, with 6 onboard sata. If I only use these ports, I don't see the issue. if there is more than 1 sata controller, the issue appears. I did several cycles of mount/umount of disk6, that is the disk attached to pci-e controller, in maintenence mode, as well as in normal mode (with SMB Export set to off), and none failed I think this bug is brought up because the umount of disk5, the last disk on the onboard sata controller, is not completelly finished when, in the sequence, the umount for disk6, attached to the pci-e controler is started what led me to this conclusion is that on my syslog , 2 disks remain busy after umount crashes the kernel. the conclusion is that the unmount of the second to last disk and the unmount of the last disk conflict with each other. perhaps from a race condition between them. I think if a small delay between umounts is added, this issue could be solved attached is the syslog with the kernel BUG info syslog.zip

Tom, could you implement a slight delay (3 seconds for example), between each unmount when the stop button is pressed on the webgui ?

I did several cycles of mount/umount disk6, that is the disk attached to pci-e controller and none failed I have a hunch: could this bug be brought up because the umount of disk5 on the onboard sata controller is not completelly finished when, in the sequence, the umount for disk6, attached to the pci-e controler is started? what if a few seconds were added between all the umount commands ? could someone create a test case, with 2 disks, one attached to a onboard sata controller, and other attached to an offboard sata controller, and a script that mounts and unmounts them in sequence ? what led me to this hunch is that on my syslog , 2 disks remain busy after umount crashes the kernel. the conclusion is that the unmount of the second to last disk and the unmount of the last disk conflict with each other. perhaps from a race condition between them. I don't have the capabilities to debug this low level kernel stuff...but perhaps someone else has

can I unmount a disk while the array is started, but in normal mode ? (not in maintenance mode) I assume I must stop samba first

well. I could mount and umount disk6 manually several times, even after several hours of disk sleep inconclusive for now...

I am testing something different. Started the array in maintenance mode, and manually mounted disk6. I will sleep all disks and let it sit for a few hours. then I will try to unmount the disk manually and see what happens

the bug reapeared. after the initial testing, I let the disks sleep and waited a few hours. after that, I hit the stop button, and the same kernel bug appeared... this time disk6 had 0 transactions replayed during the reiserfsck command... I guess it's not related with reiserfs corruption afterall is there a way to remove an empty disk from the array without rebuilding parity?

I ran reiserfsck on all array disks.. only disk6, the one the unmount was failing with, had 5 transactions played back, but none had errors detected after that, I couldn't reproduce the bug... tried several start/stop array cycles in a row, and nothing lets wait a few days and see...

an Update I did some testing, and this bug isn't related with disk sleeping. I booted the array, and did a few stop/start array cycles in a row. doing this I could reproduce the bug consistently. It really appears it is a race condition or a timing issue. but the bug manisfests consistently on the same disk always. the disk attached to the offboard PCI-e sata controller Since I aready switched sata controllers, I will try to test it with different disks, because I suspect I am always testing this with the same 1.5TB seagate drive. If this bug manifests itself with other HDs too, I guess I will have to limit my array to the 6 onboard sata ports for now... Does anybody else has the same hardware configuration as I do and is running without issues ? (Supermicro X8SIL-V + Core i3 540 + 4GB DDR3 ECC + Secondary PCI-e Sata controller) ? searching the forums for the Call Trace output (queue_delayed_work do_journal_end journal_end_sync), I found a few other members with the same symptoms, like users madburg, nezil, gfjardim it appears madburg ran reiserfsck on the disks and the problem was fixed? is that correct? how can I do this without invalidating the parity on my array? syslog.zip

Great news ! Thanks for the info I will wait for a possible fix then

intermittant, unfortunately but it only happens when I have a secondary sata controller. I tried to reproduce it several times, by sleeping all disks and then stopping the array, but I couldn't reproduce. Tried to sleep only the disk attached to the secondary sata controller, but I couldn't reproduce it either after several attempts I suspect it has something to do with how long the disks stay sleeping in conjunction with the presence of a secondary controller. if I remove the secondary controller and leave all disks with the onboard controller, the error doesn't happen (after a few months of using the server, with long sleep cycles). after I attached a new disk to this JMB362 controller, the error happened on the same day, after the disks went to sleep after 1 hour as configured. When I was using the LSI based controller, the same error also appeared occasionally . If I log on the server, /mnt is empty, which suggests the disks were unmonted. SMB services are restarted, but the stop command to mdcmd fails with the device is busy message. If I try to stop the array again or try to shutdown the server, a sync() command is issued which locks up everything lsof output doesn't list any of the /dev/sdX disks or /mnt disks if I try to unload md_cmd module, it says it's in use and cant be unloaded why did you mentioned a xeon processor ? I think the i3 540 running on intel 3420 chipset behaves as a xeon, being able to use ECC memory. Could this indicate something ?

nobody has any other suggestions ?

No. I am using a core i3 540 with 4GB DDR3 Unbuffered ECC

I have this bug since at least beta-6, including -rc2 http://lime-technology.com/forum/index.php?topic=19965.0 any suggestions?