black0ut

Members
  • Posts

    10
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

black0ut's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Well, I tried using both mknod and udev rules to create /dev/sdx, etc. but emhttp still refuses to see it. I suspect emhttp uses the kernel name for identification (which is /dev/xvdx). Anyone know how to trick the what the kernel sees? I guess my two options here are messing with the xen block driver, which would be scary, or wait for unRAID to support /dev/xvdX. Any advice would be appreciated.
  2. So now we know emhttp doesn't parse /dev for devices, because I used mknod to create /dev/hda pointing to /dev/xvda (pretty much a low-level symlink) and the webGUI still ignored it. Also, I got an email back from limetech specifically stating they only support /dev/hdX and /dev/sdX. I emailed back to see if I could get a workaround. I'm pretty sure hdparm and ACPI in general doesn't work in XEN, since all the drives are emulated, even in PV mode. I'd rather just get it working first . Speaking of which, I have successfully deployed unRAID in a Slackware 13.1 HVM domU running on a Debian Lenny (5.0) domU. I'm currently rebuilding the parity, so I'll test read/write speeds sometime over the weekend. I'm pretty certain I'll see at least a 50% hit from native, if not 75%, but speed really isn't an issue for me at the moment. Hopefully support for /dev/xvdX is easily patched in, and we'll see it in a release soon. EDIT: Parity is being build at about 21 MB/s, which isn't that bad for write speeds (80-100MB/s normal, unraid writes 4x for each normal write). It seems almost native?
  3. There was communication of it working well in virtualbox. http://www.virtualbox.org/ Yep, virtualbox is essentially xen HVM, with emulated I/O calls. In the case of unRAID, that's a pretty significant overhead due to its primary role as a fileserver.
  4. I am really interested in virtualizing unRAID since it requires very little cpu/ram, and I don't want to have to dedicate an entire box to it. My results are as follows: I've been able to install unRAID inside a PV Slackware domU, but emhttp doesn't see the /dev/xvd devices as hard drives, and thus doesn't give me an option to select them in the webGUI. I've emailed lime-tech about this issue, as it seems very minor. I wanted to have unRAID in a PV domU versus an HVM domU for two reasons. First, HVM is much slower than PV due to emulation. Second, HVM has a limit of 4 disks. I am currently setting up an HVM instance for testing purposes, but I have no doubt unRAID will work fine, albeit a bit slowly. Anyone else have success with virtualizing unRAID, preferably non-emulated I/O?
  5. Perfect. Exactly what I wanted to know.
  6. I meant the usb drive, not one of the disks in the array. Yes, however you may need to recalculate parity. The data on the drives itself would still exist. It is suggested to backup the /boot directory to save te unraid configuration and superblock. You would not need to image the flash drive, you can simply copy or rsync it. You can swap it in as long as you have a valid key for a licensed flash drive. This is the reason Limetech sells a multiple license discount of unRAID. If you are using a hard drive for a slackware install, then use whatever normal linux backup procedures that are appropriate. The license is tied to the flash drive. I only suggesting imaging as I'm assuming a complete hard drive failure, so replacement would be easiest with reimaging. So if I install unRAID over slackware, then have that disk die on me, I can be back up and running after I get a new HD, reimage, and recalculate parity? unRAID would have no problems other than the needing to recalculate parity?
  7. If the unRAID disk fails (either the usb drive or a hard drive if installed over slackware), is the information on the drives in the unRAID recoverable? Can you make an image of the drive/disk, reimage the drive/disk, and swap it in, and have it work fine?