unRAID 64bit ...

[BRiT]

I thought this might interest some of you, so here it is...

 

Out of idle curiosity, I started my efforts to determine how difficult it would be in getting unRAID to function under a full Slackware64-Current distro. This is the 64bit version of Slackware-Current.

 

Surprisingly, it did not seem to take much effort at all. I am still in the process of conducting tests, but the base functionality seems to work. I'll post updates when I hit further checkpoints.

 

The approach I took was to utilize VirtualBox to setup the experimental system. I added the SATA controller with 4 virtual 10GB disks, one for the base to install Slackware64 onto, one for parity, and two for data drives. I had to use 'noapic' parameter to boot the stock kernel. After the base OS was installed, I proceeded to create the custom kernel. I copied the kernel source to 2.6.33-unraid directory, copied over the unRAID MD drivers and configured it to load as a module. After compiling and I rebooted to verify the new kernel worked. After that I copied over the /unraid/root, /unraid/usr/local/sbin/, /unraid/etc/samba directories and subdirs. I then copied over /etc/rc.d/rc.samba, and /etc/rc.d/rc.local files. Since I couldnt exactly get the USB flash mounted, I created a /boot/config/ directory so it could at least create the config files.

 

For setting up Slackware64-Current (13.1) to be able to run more 32bit programs and to compile 32bit only versions, the following steps should be followed as listed in the Multilib Slackware for x86_64 wiki entry. This will setup a genuine environment with the needed 32bit libraries and compiler. The steps seem easy to follow, considering you already worked through installing unRAID on Slackware and creating a custom kernel. It's basically installing a few packages, running a script, then installing more packages.

 

The next part was the most tedious. It was trying to appease emhttp so it would run. This involved copying over or symlinking the needed 32bit libraries from unraid-4.5.3/lib/ directory to /lib/:

• ld-linux.so.2
  
• libcrypt.so.1
  
• libcrypto.so.0
  
• libpthread-2.7.so
  
• libpthread.so.0 -> libpthread-2.7.so
  
• libvolume_id.so.1
  
• libc.so.6
  
• libdl-2.7.so
  
• libdl.so.2 -> libdl-2.7.so
  

 

With those steps done, emhttp was able to start. I am able to browse to the management page, assign the virtual disks, start the array, format the disks, and start a parity check. The parity check is still in progress.

 

Once the parity check is finished, I will then determine what is needed to get the userfs running.

 

To get the user filesystem to function, the following additional libraries had to be copied from /unraid/lib to /lib:

 

    libfuse.so.2.8.1

    libfuse.so.2 -> libfuse.so.2.8.1

    librt-2.7.so

    librt.so.1 -> librt-2.7.so

 

The libraries were determined through the use of ldd executable, such as ldd /usr/local/sbin/emhttp or ldd /usr/local/sbin/shfs.

 

In the latest Slackware-Current releases (32bit and 64bit), they upgraded to udev 1.51, so there are some issues which seem to be of the display-only level. In particular on the "Devices" page, the disks devices display oddly, but they display properly on the Disk Status page. The Flash GUID is detected properly and displays fine. The drives mount fine as well. This is what displays:

 

parity device:   pci-0000:00:1f.2-scsi-1:0:0:0 host1 (sdb) wwn-0x50014ee2ad71c74d

disk1 device: pci-0000:00:1f.2-scsi-4:0:0:0 host4 (sdc) wwn-0x50014ee2581c623e

disk2 device: pci-0000:00:1f.2-scsi-5:0:0:0 host5 (sdd) wwn-0x50014ee202c6e6ff

 

instead of:

 

Model / Serial No.   Temperature   Size   Free   Reads   Writes   Errors

parity   WDC_WD20EADS-00R_WD-WCAVY0211284   *   1,953,514,552   -   1,641   1,860   0

disk1 WDC_WD20EADS-00R_WD-WCAVY0247937 * 1,953,514,552 1,010,462,656 10,562 1,764 0

disk2 WDC_WD20EADS-00R_WD-WCAVY0252670 * 1,953,514,552 1,287,682,996 5,520 92 0

[jimwhite]

Wow!! We must have been visited by the same alien in the middle of the night!  Only yours was about a week ahead of me.... I just started on this 2 days ago!!

[unraided]

An interesting thread, though I have a question for Limetech (which could be a very simple answer), has been any thought or is their any future proposal as to whether a unraid 64bit version would be available for those using x64 CPUs and mobo combo's? If so, having a 64bit unraid OS, the performace would still be subjected to the actual speed of the other components, ie: mobo, SATA interfaces, addon HDD controllers, HDDs themselves, correct? Or could the benefit of parity checks, write speeds, etc... in a 64bit environment be a leap forward in performance? Thanks.

[purko]

An interesting thread, though I have a question for Limetech (which could be a very simple answer), has been any thought or is their any future proposal as to whether a unraid 64bit version would be available for those using x64 CPUs and mobo combo's?

 

That's probably not high on their to-do list.  There's plenty of more interesting things that could be done first.

 

[unraided]

I would say so too, though other features or functions would probably be more of a priority then getting unraid to run at a x64bit level. I'm just curious though if performance would increase, again, pending on the servers hardware, but tasks like parity would be faster, due to calculations it needs to do? or running the OS in either 32 or 64bit makes no difference? Thanks.

[Joe L.]

I would say so too, though other features or functions would probably be more of a priority then getting unraid to run at a x64bit level. I'm just curious though if performance would increase, again, pending on the servers hardware, but tasks like parity would be faster, due to calculations it needs to do? or running the OS in either 32 or 64bit makes no difference? Thanks.

Parity calculation takes almost no cpu time on a 32 bit system.  The change to 64 bit for that reason would yield no benefits at all.

 

see this post: http://lime-technology.com/forum/index.php?topic=4390.msg40684;topicseen#msg40684

 

especially this quote from it:

One more thing I should add: the actual parity calculation - that is performing the required XOR operations in memory' date=' has a negligible effect on write throughput in an unRAID server.[/quote']

[unraided]

Thanks Joe L. for clarifying that. So, besides the RAM increase support in a 64bit environment, unraid would have no benefit what so ever, as it is fine to run with a system under a < 4GB RAM I guess.

[Joe L.]

Thanks Joe L. for clarifying that. So, besides the RAM increase support in a 64bit environment, unraid would have no benefit what so ever, as it is fine to run with a system under a < 4GB RAM I guess.

32 bit unRAID today supports more than 4Gig of RAM and unless you are doing really unusual things with your array (vmware server) 1Gig will probably do.

My personal unRAID server runs on 512 Meg of ram.

 

Joe L.

[WeeboTech]

The only benefit I see in running unRAID in 64 bit mode is faster access to very large amounts of ram.

Currently any ram over 4gb is accessed in PAE mode which has a slight performance penalty.

For use as a buffer cache, there is no noticeable difference with this "slight" performance penalty.

 

Now if you wanted to run VMWare server with a few VMWare environments running simultaneously, the 64 bit ran access would help.

 

Since this is not the target and people rarely put in more then 4gb of ram, I don't see 64 bit support bringing much to unRAID at the current time.

[unraided]

Ah, I can now see why compiling a 64bit for use like VMware would be of a great benefit, but for those who use it purely for a storage server (stock standard unraid with a few addons), your 32bit plain vanilla unraid is fine. Thanks WeeboTec and Joe L for your points.

[BRiT]

I completely agree with what Joe L and WeeboTech stated. The benefits are minor / non-existent to the typical unraid user. However, for the power users or ones already running Slackware64bit, it provides another option.

 

Yesterday I restarted from scratch, but doing the steps in a different order to ensure there were no flukes and to double check them. Basically after installing Slackware64, install the multilib packages; it lessens the number of libraries that need to be copied from the unRAID image down to 2 base ones (libvolume_id and libfuse). I'll have a revised list of steps up sometime this week, maybe even look into formatting it up for a wiki article or two.

[jimwhite]

Cool... I've halted my efforts since she who must be obeyed has been a bit cranky lately - seems I love my computer more than... well, you get the idea 

 

Looking forward to your guide...

 

 

[josetann]

I decided to attempt this as well.  Caused a lot of headaches.  Whatever config it started up with, it's sticking with it until a reboot.  I.e. my parity drive wasn't recognized, I added it back, but it kept insisting that my parity drive was not installed.  The disk.cfg was written with the correct information.  I had to reboot before it would accept the change (even killing emhttp and restarting it wouldn't work, only a reboot).

 

I'm letting it do a parity check as we speak.  I'll try to update if I come across any other problems or figure out a solution.

[jimwhite]

Hey BRiT... ever put that guide together?

[Kyrin]

Unless this is his work, I don't know that I'm seeing it... That article also doesn't talk about 64-bit, so I don't think that's it either...

[BRiT]

I never did put together a finalized guide on getting it to work, too many moving parts (unraid versions and slackware distros) but I have contributed to the unRAID 5.x on Slackware distro wiki guide.

 

My thought and intention was to put together an installpkg versions of unRAID for a Slackware distro and one for a Slackware 64bit distro that would remove the need for any of the manual steps. I had been waiting on a final release non-beta versions of the unRAID 5.x series to do so.