RasterEyes

In another thread I saw these suggestions for speeding up rsync transfers, based on changing the encryption used by SSH. Since I don't need a high level of security, and I'm much more interested in speed, I wanted to try using arcfour encryption, like this: rsync --rsh='ssh -T -c arcfour -o Compression=no -x' -PrltOuv... To enable arcfour on the receiving end, I modified /etc/ssh/ssh_config like this: Host * Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,arcfour,arcfour256,arcfour128 ...and restarted the SSH daemon like this: /etc/rc.d/rc.sshd stop /etc/rc.d/rc.sshd start (More complete that a one-step restart, and safe to do when using the web console, which won't disconnect.) If I can get this working, I'll worry later about the /boot/config/go changes needed so my modifications can survive a reboot. When I try to use rsync like this, I get this error: Unknown cipher type 'arcfour' rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(231) [sender=3.2.7] What am I missing to get arcfour working? Are there also source-side ssh config changes needed?

I think so. I'm not sure I'm getting your meaning (if you're saying you think they do suck, or they don't). The review sounded positive, however, although it was about a much smaller 512MB drive. At any rate, even though things still seem weird (like using SMB being so much faster than rsync over SSH), I'm pretty sure I've safely moved beyond worrying about the quality of the new SSD drives being an issue.

Now this is really crazy. I'm getting a much faster rsync backup like this: rsync -rltOuv --exclude={'*.bak.mkv','*.upd.mkv','*.aac'} --delete --force /mnt/user/video/ /mnt/remotes/TRANTOR_video/ ...accessing the backup array via SMB instead of using the rsync protocol. Something wrong with rsync on the backup array???

Nope, just running rsync the same way I did before. rsync -rltOuv --exclude={'*.bak.mkv','*.upd.mkv','*.aac'} --delete --force /mnt/user/video/ [email protected]:/mnt/user/video/

Stranger and stranger... at the very same time my rsync back up from my main array to my backup is still crawling along at around 25MB/sec, I was able to copy an individual file at around 100MB/sec. I know rsync has a bandwidth-limiting option, but I'm not using it.

iperf is reporting a speed of around 935Mbits/sec in either direction, so pretty close to the full bandwidth of my wired 1G network.

Just to make a liar out of me, this time a parity check is running at lot faster, around 240MB/sec. There's also a backup to my other array running now (and while these diags were collected) that was still creeping along at around 25MB/sec. terminus-diagnostics-20231012-0512.zip

Could power consumption be an issue? If my SSDs are over taxing my power supply, how would I know? Would the symptoms be outright crashing and failure, or could the slow performance I'm seeing be a symptom of needing more power? I've already thrown away the data sheets that were packaged with my drives, and I have figured out where to find that info online yet.

After rebuilding my Unraid array using all SSD drives, initial generation of parity ran at around only 25MB/sec. I was expecting a lot more speed than that. Parity checks don't run much faster (maybe around 35MB/sec). The only thing that runs quickly is transfers from the SSD array to an attached USB hard drive (as an Unassigned Device) -- that's about 10 times faster, ~250MB/sec. Network transfers from my array are now much slower than when the array was a pure HD array, from either the SSD array or from the attached USB hard drive, at only 25-35MB/sec. I have a backup Unraid array that's still built solely from HDs. I get network transfer speeds of around 190MB/sec using that array. If this were simply due to having sucky SSDs, I shouldn't be able to get that ~250MB/sec SSD->HD internal transfer rate, and network transfers from the HD shouldn't be slower than they had been before either. If this was just a network problem parity building and parity checks shouldn't be so slow, since those don't require traffic over the network. This doesn't make a lot of sense. I'm wondering if I've accidentally messed up my configuration, or if I should configure things differently for SSDs than I used to with do with HDs. I've found an earlier thread on this topic here: ...but I'm not sure I understand the issues involved in that thread. I set up my new SSD array the same way I'd set up HD arrays before, albeit this is the first time I've used 2 parity drives instead of just one. There are 9 data drives, all XFS formatted. Each drive is 4TB, for a total of 36TB storage. Any ideas about what, if anything, I might have screwed up, or could improve? terminus-diagnostics-20231011-2141.zip

I'll have to wait to give that a try, as my array is a bit busy right now. What does a USB bridge need to be "transparent" to in this case?

I just turned my Unraid system with 4 12TB HDs into a system with 11 4TB SSDs instead. There wasn't anything wrong with the HDs prior to this, I just wanted faster data transfer without mechanical delays, which sometimes caused video playback to sputter. I figured I should be able to stick these drives into an external USB enclosure, then mount them to access their content. I've got the vast bulk of what I needed to copy copied already, so I'm not at risk of losing any important data, but I just wanted to check for some stray files I might have missed. I'd also, in the future, like to be able to count on the stack of old drives as an extra offline backup. The drives don't come up as readable under Unassigned Devices, however. All I get is the option to format them. I might expect that for the old parity drive, but not all three data drives. I wasn't (at least by conscious choice) using drive encryption of any sort. Why wouldn't these drives be mountable? The external enclosure is working, as verified by a 20TB XFS drive I just mounted without any problem. terminus-diagnostics-20231003-1704.zip

I hadn't considered that. How fast can more expensive SSDs go at a sustained rate?

It's over 12 hours since I started, and still going now with 15% left to finish, expected time remaining bouncing around between 2-4 hours. The read/write speeds displayed all over the map. It's not always running this slowly, but it seldom gets faster than 100 MB/s, while the SSDs are supposedly capable of over 500 MB/s. I'd hazard a guess that 50 MB/s has been the more or less typical speed. Nothing else is going on reading or writing to the array. It has nothing to do other than build parity. Is this possibly a bus speed limitation? Too much SATA traffic going on at the same time?

I had been thinking making an SSD version of my current 36TB system, which uses four 12TB HDs (one parity drive), would be hideously expensive. But I can buy some 4TB 2.5" SATA III SSDs for about $140 US each. Ten would only cost $1400, or maybe I'd get 11 for $1540, and have two parity drives instead of just one. The cabling would be a tangled mess, however, with all of those SATA cables and power cables, unless perhaps there are solutions I'm not aware of to get that kind of cable chaos under control. I don't have that many drive bays either, and might have to settle for SSDs just floating around at the ends of cables. As for cooling and power, I'd guess 11 SSD use less power, and generate less heat, than 4 HDs. I got inspired to consider the idea of going all SSD again tonight when my wife and I were watching a movie. Playback sputtered a few times, and I was wondering if my MKV file was corrupt... but then I realized I was running a backup of my array, which had been going on for hours, and has hours left to go. The backup was probably just fighting for access time on the same HD the movie was streaming from.

I got a chance to reboot just now, and the change based on Squid's suggestion works great. Thanks.

So, should editing the go file to something like this do the trick? #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & cat /boot/config/my_profile >> /etc/profile I'd test it right now, but it's a bad time for a reboot at the moment.

I've tried save aliases, such as: # My aliases alias vsync_full="rsync -rltOuv --delete --force /mnt/user/video/ [email protected]:/mnt/user/video/" alias cdv="cd /mnt/user/video" alias ll="ls -l --time-style=+%F\\ %T" alias lla="ls -lA --time-style=+%F\\ %T" ...into both /root/.bash_profile and /etc/profile, but either place I put them, they are soon after cleared away and I have to restore them again. Is there a better place where my aliases with reliably persist?

My experiment led to another failure, but it was a different port on the same controller I had been trying, not a different controller. I could have experimented further (I have both motherboard SATA ports and an extra ports on a PCI card), but I decided to go straight to buying a new motherboard to go along with the new 8TB drives I had already ordered. Now all that remains of the old NAS I tried to press back into service as a backup system is the case, power supply, and the hot-swap drive bays. Ah, well! It's a really nice case at least. I can't find anything like this anymore. It's standard PC tower, but the entire front side of the case can be used, top to bottom, for up to 8 accessible drive bays. I'd have loved to have gotten another one like it for my new NAS, but couldn't find one anywhere. I'd never have guessed a SATA controller could go bad in such a way that it would repeatedly corrupt hard drives simply by powering up or powering down.

trantor-diagnostics-20230705-1249.zip

In around 13-14 hours I'll have the results of an experiment to see if the SATA controller is at fault. I disconnected the SATA cable from the newly-failed drive, marked that cable as potentially bad with a piece of tape (not likely the cable itself being bad, but the associated port), and then connected an as-yet-unused SATA port to the hot-swap drive bay of the failed drive. I put the OLD drive back into this position, the one I thought was itself failing, started my array back up, and now that drive is being rebuilt. When the rebuild is complete, another power cycle might tell the story. Another reason I'm suspicious of the controller, and that one particular port on the controller, is that I ended up with TWO "Unsupported partition layout" drives when I tried to swap an old but empty drive into the same drive bay as the first failed drive, got the same error, put that drive back in its old bay, and then found I'd doubled my failed disk problem. Fortunately, this troublesome array is only being used as a backup for a newer, much more reliable array, an array that additionally has two single-drive backups (one now slightly out-of-date copy a friend is holding for me).

After having had this happen a couple of times already, I replaced a drive with a fresh new drive. The rebuild of that drive just finished, so I powered down, powered up again... and BOOM. Same error for the same disk number, even though it's a different physical drive. I think it's highly unlikely that the new drive failed in exactly the same way, so what might be going on here? If the partition layout really is bad (again!), are there any partition repair tools that can be used rather than rebuilding the drive yet again? I was just getting ready to replace ALL of the drives in this ten-year-old array, all of them 4TB, with new 8TB drives, starting from scratch, keeping the old 4TB drives offline as an extra backup. But since swapping one of the 4TB drives with a new 4TB drive didn't fix the problem for that one drive slot, I'm beginning to fear that perhaps I'll keep getting the same failure even with all new drives. Could some corruption in my Unraid system itself be to blame? Can a SATA controller go bad in such a way that power cycling leads to corrupt drives? Is the reiserfs file system particularly vulnerable to such failures, so that when I start from scratch with 8TB drives using xfs instead, that might help prevent a recurrence of this problem?

I tried a little trick that got the data back without waiting. I excluded disk5 (a disk that didn't have any data on it yet) from the share, applied that changed, then re-included disk5 again. All of my data, including the for-now-emulated data, is available in the video share, without having to wait for disk4 to finish rebuilding.

Specifically, my disk4 is being recovered. I can see everything that used to be there on the path /mnt/disk4/ -- obviously data reconstructed via parity. I also have a share, /mnt/user/video/ that uses disk4. When I try to access my data via that share, however, there's a big disk4-shaped hole in that data. Does a disk have to be fully recovered before it participates in providing data to a share? Or is something else possibly wrong? I double checked the settings for my video share, and disk4 is still included in the share.

Fourth time's the charm? This time I used the Ubuntu VM running on my Macbook Air... and the drive mounted. I'll have to try into again on my Windows system.

I bought a large external drive to plug into my Unraid system as an Unassigned Device, to which I could make an external backup of my data. At first I kept the drive formatted as it was pre-formatted at time of purchase, with exFAT. This worked fairly well, but wouldn't backup my symlinks. So I decided to trade the greater portability of exFAT for the symlink support of xfs, using my Unraid system itself to perform the reformatting. I still expected to be able to unplug the drive and read it from other computers. So far, no luck. I can't read this drive from a Linux VM, from my Windows 11 system using Paragon Software's Linux file support, or from my Mac using macFUSE. Is there something I'm missing here?