limetech

Administrators
  • Posts

    10184
  • Joined

  • Last visited

  • Days Won

    196

Everything posted by limetech

  1. If that "other disk" is not in the list of disks that the share is permitted to span, the operation will fail with "disk full".
  2. Right you are. I didn't add discussion of "Included disks" and "Excluded disks" because the post was long enough as is
  3. Supports 16 now - but yes, just for you we'll consider expanding that. Have you posted this on AVSForum? Those guys would probably really appreciate your set up.
  4. Would the air flow due to convection be sufficient to cool his set up? Also there is at least some air flow generated by the CPU and power supply fans - perhaps a more strategic placement of the power suppy would help.
  5. Need to see your syslog. http://lime-technology.com/wiki/index.php?title=Viewing_the_System_Log
  6. It shouldn't make any difference from a PCI bus standpoint. We haven't found any yet
  7. That is a true rackmount! I really like your set up - it captures the essence of unRAID: how to organize hard drives in the simplest, cheapest, and most reliable way possible.
  8. Kudos! on your power supply choice, since it has a single +12V rail
  9. Couple things to keep in mind: - You probably want to have a 533MHz FSB, and - Use 2 sticks of 512MB of RAM, which gives you 1GB total, running in dual channel mode (1066MHz effective). The actual clock rate of the CPU is less important - probably 1.6GHz is fine. Don't go less though. Nice to have on-board video and GigE (on internal PCI-express ideally).
  10. daquint - do you remember which version of unRAID was used to initially format those disks? I think this problem can only potentially happen on a disk which was formatted with unRAID release prior to 4.0-beta1, and then system is shut down/crashes without doing a Stop first. This problem is not "supposed" to happen - the whole point of using a journaling file system, such as reiserfs, is to avoid this kind of problem. But I think what happened is that some change was made to the reiserfs file system between linux 2.4 kernel and 2.6 kernel, which introduced this problem. unRAID OS moved to linux 2.6 kernel starting with 4.0-beta1. I can't yet prove this is the case, but the original reiserfs developer may not have been able to sign-off these changes, due to being in jail on suspicion of murder (Or perhaps was just distracted??)
  11. Yes I agree 'split level' is very confusing & hopefully we'll figure out a better solution. It might help to understand what is the problem we are trying to solve: 1. On the one hand, we want to let the system store files under one network share across multiple disks. 2. On the other hand, there are times when we want certain "sets" of files to be stored on a single disk. What is a case of a set of files that we want to store on a single disk? Well it's the set of files that make up a single media. For a movie, it's the IFO, VOB, folder JPG, XML metadata, etc. files. For music, it's all the files associated with a single album (the music data and cover art files). We want these files to be on the same disk so that as we read the media there won't be a 'pause' when the player accesses a file on a different disk which happens to be spun down. Getting back to 'split-level' - realize first that individual files can never be split across disks - that is, suppose you want to create a single 1GB file - well it will exist as a single file on a single disk - there's no way we can put say 100MB of it on one disk and 900MB on another. If we used one large file system spanning multiple disks then of course this could easily happen - but not with unRAID because each disk has it's own file system. So, when we talk about "splitting", it means splitting a directory. Now say we want to create a file. That file will always be in some parent directory. So we find out which disk the directory is on and create the file in that directory on that disk. But what if the disk is too full? So we pick another disk. If the parent directory does not exist on the disk we picked, then we must create it on that disk first, then create the file. Note that we have just split the directory. We also have a situation where the same directory exists on more than one disk. The "share" file system which is part of unRAID OS sorts this out and presents all the files which exist under that same directory on all the disks as if they were all on just one disk. Now back to the case where we don't want to have a directory split. Say the file we are trying to create is the 2nd VOB file of a movie. We need to guarantee that this file will get created on the disk where the parent directory exists, regardless of how full that disk is becoming. Well the way we accomplish this is by looking at how deep in the heirarchy is the parent directory. Say the name of the parent directory is "Maui2007", and the grandparent is "Videos" - further, the "Videos" directory is also the top-level directory, which means it's the share name. We're going to say that the top level (share name) directory is level "1" (the "Videos" directory is then level 1). The "Maui2007" directory would be level 2. Any object (file or directory) under the "Maui2007" directory would be level 3. We will set the "split level" to 1, which says the system has permission to split any directory at level 1 (or lower) across multiple drives if it needs to. So if we create a new object (file or directory) under "Videos", then we can pick which disk to actually create it in. So when we created the "Maui2007" directory, the system was free to pick which disk to create it on. But if we create a new object under "Maui2007" (which is level 2, which is greater than split level), then the system can not pick any disk to put the object on - it must use the same disk that it's parent directory is on. Hence, all the files in "Maui2007" directory will be kept together on the same hard disk - make sense? Note - when a share is created which is permitted to span multiple disks (ie, split level > 0), the actual directories do not get created until they are needed. That is why when you create a share, it's corresponding top-level directory is only on one disk. As you add files to the share, it will eventually spill over to another disk and at that time the parent directory(s) will be created. If you set split level to 0, that means which ever disk the system picked to create the top-level directory on, all objects created in that directory will be on that same disk. If you set the split level very high, say 99, then any time the system creates a new object (file or directory) it is free to pick which disk to create the object on. If you always have all your drives spun up, or you don't mind waiting for a drive spin up, this setting would assure the most even distribution of files across all your disks.
  12. Type this command and post the output please: cat /proc/net/dev
  13. Right, unRAID does not support any RAID card drivers. Go into the bios of your RAID card and set it up for JBOD mode.
  14. The unRAID driver does not add any additional timeout or retries - all such error recovery is done by the lower-level drivers. All recovery actions taken by the unRAID driver are as a result of 'fatal' error being reported by the lower-level driver: When a disk-read has failed: unRAID driver will attempt to read parity plus all the other drives in order to 'reconstruct' the missing data. Once this is accomplished, this data is sent to the requestor, and then the driver attempts to write this data to the disk which reported the failed read. If this 're-write' also fails, then see next paragraph. When a disk-write has failed: unRAID driver will immediately 'disable' the drive. If the array has valid parity then the written data will be retained (via parity logic) and 'success' is reported; otherwise the request failure is reported. Note that in read error recovery which involves reading all the 'other' disks, there could be a significant delay if one or more of the other disks are spun-down. This of course is unavoidable. Here's my take on TLER: it's just non-sense I suspect it was added at the request of some very large hard drive customers who found it easier to strong-arm the hard drive vendor, rather than fix their firmware, at the ultimate request of uninformed end-users. Look at this way: if a hard drive is taking longer than 8 sec to recover from an error, you probably want to have it disabled. Also, I think TLER might have some historical roots. Long time ago several high density (for it's time) drives would periodically execute an internal "recalibration", where the heads would seek off to some special cylinder for the purpose of thermal recalibration. If an i/o request came to the drive during this period, there indeed would be a substantial delay which didn't necessarily mean the disk was bad. I don't believe any hard drive built in the last decade or more does such nonsense anymore. The other historical root would be with video applications. I can remember SMD hard drives which had a programmable mode where all retries were eliminated. This was because the data was streaming off the drives at the video rate & it was deemed less of a problem seeing a small glitch in a line or two of a video frame vs. massive frame-loss jittering which would occur if the video stream was interrupted due to disk retries.
  15. I'm not sure about the on-board Marvell SATA controller. Refer to this: http://www.linuxcompatible.org/88SE614x_SATA_II_PCI-E_Controller_c13457.html There are driver changes necessary to move to 2.6.23.x kernel, which may or may not get into the next unRAID release.
  16. We'll incorporate the latest Intel driver in the next unRAID release - might fix this problem. Next release should be in a few days.
  17. Both of those m/b's should work, but you'll need to get a cheap video card.
  18. From the console or telnet session you can type: mdcmd check to start a parity-check, and mdcmd nocheck to cancel it before completion. You can look at what 'mdcmd' does and set up a cron script to do this periodically. When I get time later I'll try to post better instructions for this - or perhaps someone else can in the meantime.
  19. Starting with the next release (4.3) the .config file will be included in the /usr/src/linux directory on the flash - we should have included it all along - just an oversight. One reason the kernel is "conservative" is because there is no swap space allocated. Once you start running out of memory the kernel randomly kills processes. May not make very next release, but soon we'll be adding kernel support for more memory, and swap space on an array disk or external usb/sata disk/flash.
  20. Still there, but I haven't been there yet... so many brew pubs but so little time
  21. The move is finally complete - we're now in Fort Collins, CO, and I must say, what a great place this is! Until all the business details are sorted out, as of today, all products will be sales tax free.