Hello,

 

I am currently testing out unRAID to see if it meets my needs.  I am currently running into a physical space issue with my DVDs and BDs where I live.  I am currently considering moving the DVD contents to exact copies on my local network and storing the physical media.  unRAID came recommend to me for that type of application.

 

I am currently testing with the following (What I had available - not what a final server would be):

 

• ASUS P8P67 DELUXE (REV 3.0) LGA 1155 Intel P67
  
• Intel Core i5-2500K Sandy Bridge 3.3GHz LGA 1155 95W Quad-Core Processor
  
• G.SKILL Ripjaws X Series 32GB (4 x 8GB) 240-Pin DDR3 SDRAM DDR3 1333 (PC3 10666) Memory
  
• 2x Western Digital Caviar Green WD10EARS 1TB 5400 RPM SATA 3.0Gb/s Hard Drive (Data Drives)
  
• 1x Western Digital Caviar Green AV Drive WD10EVVS 1TB 7200 RPM SATA 3.0Gb/s Hard Drive (Parity Drive)
  
• COOLER MASTER Silent Pro RS850-AMBAJ3-US 850W ATX12V v2.3 / EPS12V v2.92 Power

 

I have a few questions/Problems.

 

Since using the free version to test I can not use a cache drive and that may address odd behavior I am seeing with rates right now.  If I copy files to the unRAID server I start at 50MB/s and then drop down to about 2 MB/S and then go back up to about 40MB/s back to 2MB/s, rinse and repeat.  Outside of the unRAID environment I see much higher rates on writes and steady rates on the same drives (Granted not in a redundant setup). My guess is since the parity is handled in software that the writes use a small cache and flushed out to the physical disk quite often to get data and parity to the disks. 

 

Without a cache drive the sea-saw effect I am seeing on write speeds expected or unexpected without a cache drive?

 

Reads seem to be a steady 49MB/s for files on a first access and then 108MB/s (basically saturation point for Gbps network) once cached. 

 

I am having seeing an issue is with support for Unicode characters.  While on the network share and locally on the console in a command prompt the directory and file names with non-ASCII/latin-1 seem to work.  However, if I attempt to use the web interface to browse the directory structure I do see errors on the console from getfattr and stat.  These messages appear to be directly to stdout or stderr and not though syslog so I can not grab a log.  Some of the characters that seem to always trigger the issue is O with umlaut Ö, along with ÿ, and ü (forums might not encode those correctly).  Some Kanji also seem to trigger this issue but usually when looking at files inside a directory using Kanji names.  The timestamps for the affected files are correct at command prompt but in web interface show incorrect timestamps. 

 

Does anyone else use extensive non-ASCII characters in the names of files and directories on the server?

 

If so do you encounter issues with data outside of the web interface?

 

I am concerned that if encode/high bit character set support is not consistent throughout unRAID I may have data issues in the future.

 

Looking at the Hardware Compatibility wiki it says up to 64GB of memory is supported.  However, I see the software itself is a 32 bit application and a 64 bit version is in beta. 

 

How much memory can effectively be used by the server?

 

Is extra memory only used for mostly read caching as seems to be indicated by the performance I am seeing in testing?

 

If I do not run add-ons/plug-ins is there any major performance advantage for using additional memory beyond 2GB or 4GB?

 

I see that some functions may have issues with large drives if there is not more then the minimum required memory installed.  Is there any recommendations/calculations that can/should be done based on the planned final server disk farm size to calculate memory needs?

 

For CPU in a basic server with no additional plug-ins will multiple cores be utilized and offer any noticeable performance increase?  Will Dual Core with a higher clock rate give overall better performance then a Quad/Hex Core with a slower rate?

 

My current testing with just file serving seems to be mostly staying on a single core and I almost never break 27% CPU usage (just 2% over a single core).

 

Thanks for any help,

Tom

 

Some more information on the directory name issue I've been seeing with non-ASCII characters.  Seems the forms do not like the size of my attachments so adding links to images of the errors.

 

The errors that appear on the console:

http://www.sobhrach.com/photos/directory-names-console.png

 

What shows in the web interface:

http://www.sobhrach.com/photos/directory-names-web.PNG

http://www.sobhrach.com/photos/directory-names-web2.PNG

 

What the actual directory names on on the disk:

http://www.sobhrach.com/photos/directory-names.PNG

 

I've done more testing on the write speeds and it appears the disks with parity seem to cap at ~22MB/s write speed and the sea-saw I see across the network appear to be due to cache flushes and syncs.  This seems lower then I expected even with the green drives I am testing with.  I may retest with some non-green drives this week if I have time.

 

 

32GB ram on a 32bit OS.  What you are seeing is the effect of the page cache filling up as you transfer a file then a flush occurring which basically halts the transfer until the dirty cache is written, then proceeds to fill cache again until another write is triggered, rinse repeat.  The (32bit) Linux VM subsystem was set up back when ram was expensive and users did not have large amounts of it, and it has not kept up with the times.  The VM subsystem is tunable and Google is your friend, but there are limits with a 32bit Linux.  Your hardware may be a bit overkill for a simple unRAID storage server, I suppose you intend to virtualize?  There is another workaround, search the forum for 4095M.  It basically limits the amount of ram available to 4G, which is the limit for a 32bit OS without using PAE.  Same effect as yanking your memory modules.

I was aware of the normal 32 bit address pointers.  What confused me was these two WIKI entries:

 

http://lime-technology.com/wiki/index.php/Hardware_Compatibility#Memory

Minimum 512MB, maximum 64GB, recommended 1GB (or more if you will be adding other applications)

 

http://lime-technology.com/wiki/index.php/Building_an_unRAID_Server#Hardware

Memory (RAM): Minimum 512 MB, but 1-2 GB is recommended. 4+ GB is recommended for certain unRAID add-ons.

 

That plus different tools at the command prompt seemed to detect all 32GB.  I was not sure if what was sent with unRAID had PAE and did any special page management for caching.  That's what prompted my "How much memory can effectively be used by the server?" question.  It sounds like it has the standard 4GB limits in place for most things.

 

The hardware I used for testing was just what I had setup and not in use and did not feel like reconfiguring it. 

 

My bigger worry is the UTF-8/UNICODE 2-byte character support and if the problems I saw are limited to the web interface only or indications of a larger problem.  That's what has had me hold off on a purchase at this point.