limetech

Administrators
  • Posts

    10184
  • Joined

  • Last visited

  • Days Won

    196

Everything posted by limetech

  1. We have not tested that exact card. However, according to the following link, it's supported by the same driver that supports SATAII150 and SATA300. http://linuxmafia.com/faq/Hardware/sata.html
  2. Yes, you can use the on-board SATA ports as well as Promise SATAII150-TX4 or SATA300-TX4 add-in cards. We'll be posting a document to the website soon which describes how to set this up.
  3. We're looking at performance issues now - trying to make writes faster & let reads have priority over writes enough to prevent lost video frames. Current s/w write performance peaks somewhere around 11MB/sec. (11 mega-Bytes per second). There are both network issues and disk issues to address.
  4. The timezone stuff is a bit problematic. Including all the various timezone files would take up nearly 5MB on the Flash and require a fairly elaborate user i/f. Not only that, but many timezone files become quickly obsolete because many local laws defining daylight time change yearly. So the roadmap for timezone support is as follows: 1. Implement "standard" timezone selection without regard to daylight time. This will ensure timestamps are correct, but you must manually adjust the time on daylight/standard transition dates. This is the support we have now - excpet for the bug [but we'll fix the bug before making the release generally available] 2. A future upgrade will permit you to copy a "custom" timezone file onto the Flash. We would make all the "current" timezone files available on our website (or links to them). You would select the one for your locality, download it, and copy to the Flash. Then the server would use that timezone file & be able to automatically ajdust for daylight time transitions.
  5. There are two steps to the workaround: 1. Set your timezone (forget about the time), Stop arrary, Reboot, then 2. Set your local time. The 'localtime-copied-from' link is correct. The way the timezone files are named in '/usr/share/zoneinfo/Etc' is misleading. The numeric offset after "GMT" in the file name represents the number of hours you must add to your local time to get GMT for that timezone. Joe, here's the bug. There is a "first_time_called" flag in the function localtime(). The first time a process calls localtime(), the code reads the timezone info from the file /etc/localtime. BUT, subseqent calls to localtime() do NOT re-read the file. When you change the timezone in the Management Utility, all it does is change the /etc/localtime file (and /etc/localtime-copied-from). So the running process (Management Utility) timezone conversion is messed up. (The fix is for the Management Utility code to call tzset() after changing the localtime file.)
  6. Yep, there's a bug Actually, it's sorta working... If you go to the managment page and set a time and timezone, the page will show the wrong time if you change the timezone, but if you exit the Management Utility (i.e., reboot), when it restarts you will find that the time and timezone you set are now correct! (Had to plow through the source of localtime() in glibc to figure this one out; I can give the gory details if anyone is interested.) So the workaround is this: First go to the Management Utility and set your timezone, then Stop array and click Reboot. When system is back up, go to Settings and set your local time.
  7. Out of 100's of these trays we've never had a single one bad (probably you didn't want to hear that) If you want, I'll send you a tested one from our stock - just email me at [email protected].
  8. 1. Yes the D915GAGLK is what we use in the SATA development. This card has 4 SATA ports, but only 1 IDE port (2 disks). 2. Currently shipping Flash now includes the latest code. 3. Never used the "Fasttrack" card. We have used the SATAII150-TX4 and the newer SATA300-TX4.
  9. I'm looking for a couple volunteers to download and install the next release of the UnRaid firmware. As soon as we've worked out the kinks (if any) in this process, then we'll make the release generally available. The download consists of a 26MB zip file. If you are interested in participating, please send email to [email protected]. Here is the contents of the download readme.txt file: Lime Technology, LLC UnRaid Firmware 2.060315 Release Notes ====================================== Firmware Upgrade Instructions ----------------------------- Upgrading the UnRaid system firmware consists of unpacking the downloaded zip file and copying the contained files onto the USB Flash. The following 3-step procedure assumes this will take place using a Windows XP system. Important: Do not use any utility to re-partition or re-format the USB Flash; doing so may render the Flash unbootable. STEP 1. Navigate to the 'system' directory of the Flash share on your server, and, delete the 'previous' directory and rename the 'current' directory to 'previous'. Find your server under My Network Places and click on the 'flash' share. Then click on the 'system' directory. The 'system' directory contains three directories: current - contains the "current" firmware previous - contains a "previous" revision firmware grub - contains system files necessary for booting There is enough room on the Flash for two sets of system firmware, contained in the directories 'current' and 'previous'. By default, when the UnRaid system boots, it will load the firmware contained in the 'current' directory. It is possible to interrupt the boot process by pressing any key during the "GNU GRUB" menu that appears immediately following the motherboard bios startup. You may then have the system boot the firmware contained in the 'previous' directory by selecting it in the GRUB menu. This feature has been implemented as a way to "fall back" to a previous firmware version. STEP 2. Copy the 'current' directory from the unpacked 'UnRaid-2.060315' folder to the Flash 'system' directory. Using Windows explorer, drag the 'current' directory into the Flash 'system' directory. STEP 3. Reboot the server. You may either simply power-off/power-on the server, or at the console, or telnet window, after logging in, type the command "reboot". Additional Information ---------------------- Starting with this release, the 'go' script has been moved from the root directory of the Flash to the system firmware directory, i.e., either 'system\current' or 'system\previous'. If you made any customizations to the 'go' script you will need to edit the new 'go' script and place your changes there. You can leave the old 'go' script on the Flash if you want, in case you ever boot version 1.050930 again. The firmware directory also contains a 'go-sata' script. This can serve as a template for creating your own 'go' script which sets up SATA drives. Refer to the Support page on our website for more information about SATA support in this release. Summary of changes from 1.050930 to 2.060315 -------------------------------------------- - New Feature: SATA support. Upgraded to Linux kernel 2.4.31 for added SATA stability. Supports Intel SATA (ata_piix module) and Promise SATAII150-TX4 (sata_promise module). - New Feature: Added timezone support. - Improvement: Incorporate latest Marvell Yukon GigEthernet driver. - Improvement: Enable RX Polling (NAPI) in both Intel PRO/1000 and Marvell Yukon GigEthernet drivers. - Improvement: Numerous changes to the Management Utility to improve responsiveness. - Improvement: Improved parity-sync performance. - Improvement: Disk statistics are now cleared each reset. - Improvemeht: For Intel D865GLCLK motherboard bios, no longer necessary to set Advanced/Drive Configuration to [Legacy] (it can be set to either [Legacy] or [Enhanced] - latter needed to access on-board SATA). Note that if you want to re-boot version 1.050930 firmware, however, you must ensure this is set to [Legacy]. - Bug Fix: Fixed interoperability problem with Firefox 1.5 where clicking a button would cause the window to continually refresh. - Bug Fix: Fixed problem where 'System' and 'Hidden' bits were not working correctly on shared files. - Bug Fix: Correct SO_RCVBUF typo in smb.conf. - Bug Fix: Fixed problem recognizing "factory-cleared" status on certain new disks. - Bug Fix: Fixed problem which caused Management Utility to crash if a disk is disabled and exactly 1 other disk is missing or wrong. - Bug Fix: Fixed problem where system still "remembered" removed disabled disk identity. - Other: Added missing license.txt file and included source code of modifed GPL files. Known Issues ------------ - When the array is stopped, there is a button on the Management Utility to re-boot the system. After clicking this button the UnRaid server will reboot and the Management Utility will display the message "Wait...". The Management Utility will not automatically reconnect to the server, however. After the server has been rebooted, you can manually reconnect by clicking the Refresh button. - SATA support has the following restrictions: 1. Can not read SATA hard drive temperatures. 2. Can not spin down SATA hard drives. 3. Supports only Intel on-board SATA controllers, and Promise SATAII-150 TX4. 4. System occasionally will "hang" writing the Master Boot Record of new SATA disks. Upon manual reset, the disk MBR is correctly written and you can proceed.
  10. Yep that's a typo, but in practice, it's essentially equivalent. For a good read on this subject, refer to the following: http://www.psc.edu/networking/projects/tcptune http://www.redhawk.org/print.php?sid=39 An "unknown" for me at the moment is to what extent Samba fiddles with socket options - probably will have to study the Samba code to understand this before making tcp tuning decisions.
  11. Actually, SO_RCVBUF and SO_SNDBUF are both set to 65535. Last time we worked on Samba performance, found these were the optimal settings. Also, 'read raw' and 'write raw' are set to 'Yes' by default. MTU settings can be changed by the 'ifconfig' command. Again, last time we were trying to improve ethernet performance, didn't find much improvement going to larger frames, even with jumbo-frame-supported switches. Turns out there's a lot of tweaking to do, both on linux side and windows side to wring out better performance. Maybe one of our community members can experiment a bit with this?
  12. The current shipping UnRaid Flash only supports Intel PRO/1000 and Marvell Yukon. Next release also includes Realtek 8169 support. A cursory look at the Realtek support download page looks like all their GigE chips are supported by the same linux driver, so the built-in Realtek support might work for you. What motherboad do you have in mind?
  13. The long-awaited update is very very close. (I know you've heard it before.) There are a few reasons for the delay. First, I'm extremely paranoid about releasing anything that could possibly cause data corruption. First rule in storage: don't lose the customer's data! As a result, we check and recheck code changes and perform rigorous testing. For the upcoming release we moved to a newer kernel (2.4.31) which seems to solve some of the "dma error" problems. Another delay was caused by one of our development system's hard drive crashing! (I swear this is true!) Also, as you know this will be the first downloadable update, and I'm anticipating a lot of customers are going to want to update, so we must do all we can to ensure it goes smoothly. So thank you all for your patience. Once this first one is done, subsequent releases should be far less painful.
  14. Your syslog was completely filled with a bunch of spurious Samba messages, so I wasn't able to gleen anything from it. (Samba is the linux application which implements Windows network shares.) When you replace a disabled disk, or change out an enabled disk for a larger one, what happens it that the parity-rebuild operation will write the contents of the original disk to the new one block-by-block. This results in the new disk taking on the "format" of the original disk. It doesn't matter how the new disk is previously formatted - it could be brand new (all zeros), could have NTFS, could have all random data - whatever was there, gets overwritten with whatever was on the original disk. Meanwhile, any normal writes for that disk result in the block being written on the disk as well as updating the parity disk; and, any normal reads from that disk result NOT in reading the disk being reconstructed, but instead, reading all the other disks and returning the rebuilt data on-the-fly. I know this is a bit confusing & I hope to get around to writing a tutorial on the subject, but realize that any new disk does not need to be "preformatted". The fact that after an array reset, your new disk came up "unformatted" tells me that parity-sync never got started before, and there must have been some kind of error almost immediately.
  15. I think you meant it has an 82540EM chip, which is in the PRO/1000 family and should work fine with the current UnRaid s/w. http://www.intel.com/design/network/products/lan/controllers/82540.htm
  16. The UnRaid Management Utility in system firmware versions 1.050826 and 1.050930 does not work correctly with Firefox 1.5.x browsers. It does work correctly with Firefox 1.0.7 and IE6. This problem is fixed in the next UnRaid system firmware release. The problem has to do with how IFRAME's are handled in Firefox 1.5.
  17. Sorry. Use Start->Run->telnet to connect to the server & login as 'root' (no password). Then type: cat /var/log/syslog cut the text from the telnet application.
  18. Well I manually tried all 3 cases of data disk "upgrade": 1. No disks disabled - power down; replace small disk with large one; power up; Start. 2. Disk disabled, but still present - power down; replace old disk with new disk; power up; Start 3. Disk disabled, disabled disk removed - power down; install new disk; power up; Start All worked as expected Rich, can you capture syslog and email to me?
  19. Errors is the far right column on the Main management page.
  20. The behavior you see would occur if there was an i/o error during the rebuild onto the new drive. Did you notice if the Errors counter was incremented for the now-Disabled drive? To try the rebuild again, power-off, remove the drive, power up & start - drive should still be Disabled, but now missing. Now power down again, check drive cabling/mounting/etc, power up & start - rebuild should start on drive. I agree, we need to make major improvements to error case isolation and usability.
  21. Yes, I should have mentioned, also supports on-board Intel ICH5/ICH6.
  22. We understand the requirements of the GPL.
  23. Current kernel is 2.4.29. Initial SATA version only supports Promise SATAII150TX4 and SATA300TX4.