SS4000-E Can't copy large files to RAID 5

[idata]

I have an SS4000-E and for the last year had used it with only one WD 1.5TB HDD. I need more space, and wanted to use RAID 5 to have reliability, and also keep maximum space, so I bought 3 more WD 1.5TB drives and built a RAID 5 array using all 4 to get a 4.5TB RAID. I am running the latest 1.4-b710 firmware. I configured a "home" share of 1200MB, I will use the "user" directories in the home share to back-up 2 MacOS systems, and a "public" share of 1024MB I plan to put shared music and picture files, etc; and have created a disk backup using the back-up software to use some of the remaining space to backup a Windows 7 machine.

Using only 1 hard drive, I could copy files over at about 9MB/s using 100Mbps LAN, or 11 or so using Gigabit. If I had multiple systems writing simultaneuosly it would go abit slower, but no problem.

Now with RAID5 I can only copy to the NAS at about 2MB/s (regardless of 100Mbps or Gigabit LAN. And if I try to access from multiple computers, my PC will timeout and fail to write. The back-up software I am using on the Windows 7, or MacOS will work (painfully slowly) but copying files fails due to time-out.

If I log into the NAS webpage, and look at system status, it will show CPU utilization as 100% busy, 0% idle, and RAM as only 3656KB free, mostly all used in other words.

I bought this device because of reviews I had read saying it was OK running RAID 5, and ultimately planned always to use it in RAID5 setup, but it appears the CPU / RAM are not able to process RAID 5 ECC generation fast enough for multiple devices to access it.

Is there anything I can do to fix this, or something I have configured incorrectly?

[idata]

littje,

I can give you some theories and local results, but can't explain the readings you're getting. 2 MB/s is pretty low.

We know that RAID 5 will perfrom less than a RAID 0 because of the parity calculation required on writes. RAID 5 writes could be about 60% of read speeds.

With the SS4000-E the processor is the key limiting factor for performance. The system can never achieve full wire speed.

In our informal lab testing, we've seen RAID 5 8 MB/s write and about 12-13 MB/s read speeds.

You'll see some loss due to the general inefficiency of file-based operations. In our lab tests we can get better results with block-based operations.

I just tested my system here and only saw about 4.2 MB/s write speeds transferring a pretty large (267 MB) file from Windows XP to the SS4000.

Regards,

John

[idata]

In my case, some files are up 7GB or larger, is there any software or protocol changes I could do to avoid the large file being treated differently?

If I have the "client backup and recovery" software running, it is also slow, but it doesn't fail. Similarly, I am using "Carbon Copy" software on my Mac systems, it creates an image file, and then writes into this image file, using that method, it seems to be able to write any size file, just slowly.

From what you are saying, maybe the problem is the NAS is trying to somehow hold the entire 7GB file in RAM and create the parity before writing? Or swaping out large chunks to disk, then re-writing?

Whatever it is doing, for huge files, it will time-out most of the time, and always if any other system is accessing it, which is not easy to guarantee to avoid when the system is running so slowly it takes hours to copy a single file.

Are there any methods to create a disk image, and copy into that image, similar to how the Mac software is working, but in Windows?

[idata]

littje,

I created an 8GB file and copied it from my Windows XP desktop to a share on my SS4000. It took 35 minutes for an effective transfer rate of 3.8 MB/s. The file transfer completed successfully.

There's nothing I know of on the SS4000 you can do for files to be treated differently. It's not the SS4000 that's initiating the file transfer, it's the client system. Probably more specifically you backup software.

The SS4000 uses a single Intel® XScale® 80219 processor, has an Intel® 31244 SATA Controller, dual Intel® 82541 Gigabit Ethernet Network controllers and 256MB of DDR SDRAM. The SS4000 software is a proprietary Linux Kernel build based on version 2.6. Nothing extraordinary happening there.

I don't think the SS4000 can hold the entire 7GB file in RAM, it only has 256MB to work with. It's more likely to use swap space. Another tried and true Linux process.

What I was talking about with RAID 5 perfroming less than RAID 0 because of the parity calculation required on writes is standard RAID stuff. RAID 5 (software RAID here) needs to use the processor and memory to perform the calculation to write the parity stripe on data writes for RAID 5. This is standard stuff. The parity provides the ability to recover from a single disk failure by being able to recreate the data from two remaining data chunks and the parity information.

The only backup software we've validated on the SS4000 is the included Client Backup and Recovery software. We don't know how any others will perform.

One thing to consider is that the SS4000 is an "Entry" level storage system. It's not meant for big(ger) networks. I'm sure the multiple system accesses will tax the system capabilities. As you've noted you see high CPU utilization. Maybe you could schedule your backups so they don't overlap. Or use a differential or incremental backup plan that gets the full backup out of the way on the first backup (at your scheduling convenience) and then just writes much smaller changes.

Regards,

John

[idata]

I installed the "Client Backup & Recovery" software on my PC. Previously I had mostly tried to use "Sync Toy" (Microsoft app that sync's directories).

Using the app, I did a full backup of my HDD and it seemed to work, I also was able to do two incremental backups successfully, much faster too since it only copies changes.

However, now the backup softwore shows "The backup disk is not available"

I have tried using the "Repair connection" option in the "actions" menu, it claims to succeed but it doesn't work.

If I access the disk as a normal share, it works fine, and my Mac systems using "Carbon Copy Cloner" are still able to access it fine. Just in case I have rebooted everything in my network, uncluding the SS4000-E and other things. Still no luck.

In my device manager I have seen that "FALCON IPSTOR DISK SCSI Disk Device" has a yellow '!' if I open it, it says "This device cannot start. (Code 10)"

I am not too enthusiastic about using backup software that I can't even access the backup once I have created it. How do I fix this?

[fhaw]

Hello

the file that are being tried to copy is large so that it creates problem to copy. first of all file should be shorten or use long path tool to copy.

_____________________________________________