tdoris

I had to reset my passwords as well. Looks like user share performance has increased quite a bit. Write speeds are doubled to my cache drive now. Still only half as fast as writing to the cache disk directly, but I'll take it. Here is the script I'm using (its a modified version of the one posted in the beta 8 thread using a larger block size of 4k) #!/bin/bash if [ ! -z "${1}" ] then TMPFILE="${1}" else TMPFILE="test.$$" fi trap "rm -f ${TMPFILE}" EXIT HUP INT QUIT TERM echo "`date` writing to: ${TMPFILE}" dd if=/dev/zero of="${TMPFILE}" count=1000000 bs=4k echo "`date` Done." ls -l --si ${TMPFILE} echo "`date` reading from: ${TMPFILE}" dd if="${TMPFILE}" of=/dev/null bs=4k echo "`date` Done." rm -f "${TMPFILE}" Using user shares I get 28.5 MB/s write and 148 MB/s read (SSD drive) Using the cache drive direct I get 51.6 MB/s write and 212 MB/s read Any chance we could see network bonding in a future release?

High CPU usage by shfs is to be expected. This is the FUSE-based process that is implementing the 'share' file system. FUSE tends to be CPU-intensive. I'm more interested in the 'stuttering' you are seeing. What do you mean by "I'll generally see stuttering at times in one"? You have one write stream (the one recording) and one read stream (the one you're watching), did you mean to say, "I'll generally see stuttering at times in the read stream"? Two more questions: 1. Are these streams accessing the same data disk? 2. Have you changed 'md_num_stripes' and/or 'md_write_limit' from their default values? Generally what cause this is as follows: 1) I'll start using livetv on both my hd100 and hd200 receiver boxes on two different HD (1080i) channels 2) This causes sagetv to start 2 recordings (write streams) and 2 playback (read streams) to my cache disk 3) Periodically (usually when CPU utilization reported by top exceeds 100%) I'll see stutter in 1 of the playback (read) streams. This doesn't happen in 4.4.2, but does happen in all of the 4.5-betas I've tried. CPU utilization seems to be a factor of 3-4 times higher than in 4.4.2. I've tried playing a bit to with the md_num_stripes and md_write_limit, but it doesn't seem to be making much a difference. CPU utilization seem less in beta8 then beta7 (where I couldn't adjust the md parameters). If this is just the way 4.5 is going to be, has limetech been looking at any newer motherboards to be officially supported? I'd like to get something that supports 4 PCI-e x8 slots like the Asus M4A79 Deluxe, but if there is something else in the pipe I'd definitely consider getting it instead.

I'm still seeing very high shfs cpu usage with this release compared with 4.4.2. If I have 2 HD streams active recording and playing back (sagetv live tv), I'll generally see stuttering at times in one. I don't believe this should be happening with the CPU I'm using (AMD Athlon Dual Core Processor 4850e) with an ASUS M2R32-MVP motherboard. I posted a syslog in the Beta 7 thread, but I'll attach another one.

4.4.2 works fairly well, but isn't perfect. The 4.5.7 series haven't been working too well for me. I think my NFS issue is actually related to a CPU utilization problem I'm encountering. The other main use for my unRAID box is as storage for SageTV recordings. Anytime I use the livetv function and have a scheduled recording at the same time I experience severe stuttering with 4.5.7. 4.4.2 works fine. My recording share is set to use my cache drive (an 80 GB Intel SSD at the moment). I'm attaching syslogs and output from top showing the much heavier CPU utilization.

Currently one of the things I'm trying to use unRAID for is NFS disk storage for some of the non-critical VMs on my XenServer. Pretty much all of the v4.5 betas (including beta7) I've tried cause problems where the NFS storage gets dropped. On the XenServer, I can see NFS connection timeout messages. I know FUSE has a history of issues with NFS and I've seen some other messages here indicating various issues with NFS. Would be best for me to setup things differently (perhaps file based iSCSI disks being accessed via a SMB share on the unRAID box) or is there hope that the NFS issues will be solved soon?