Fair enough. I'll shut up then.

 

Not quite how I meant it. I'm saying that, given the fact that I can transfer large files given a certain directory, it doesn't follow that a power supply issue is to blame. As in, I can't transfer files to directory X, but I can transfer files to directory Y. I've never seen a power supply make that happen lol.

Search this board and you'll find that bad power supplies or connections are often responsible for the most obscure problems. I can't help you any more from the information you have supplied. I've given you a few pointers and said what I would do. They might help, or possibly not. Maybe someone else has a better suggestion.

 

What mount point, exactly, are you copying to successfully? I suspect from the way you phrased things that you are copying directly to a disk share, bypassing the user share system.

 

Do you understand how unraid creates and presents the user share file system from the disk and cache shares?

I have a user share called Media. Within that I have a personal folder, a work folder and a Movies folder. I had been copying directly within the Movies folder (//unraid-ip/Media/Movies) before, in several-file chunks (5 or so at a time) until one set of movies/chunk refused to transfer because it said there wasn't enough space. So I moved to the user share root (//unraid-ip/Media) and copied my Movies folder itself to the Movies folder on the share.

Search this board and you'll find that bad power supplies or connections are often responsible for the most obscure problems. I can't help you any more from the information you have supplied. I've given you a few pointers and said what I would do. They might help, or possibly not. Maybe someone else has a better suggestion.

 

Apparently it is in fact a Corsair power supply, I was mistaken (recalling from memory rather than looking in the box itself)

 

I've also just swapped it out for an EVGA 500w and the problem persists. Thanks for your help, in any case.

I have a user share called Media. Within that I have a personal folder, a work folder and a Movies folder. I had been copying directly within the Movies folder (//unraid-ip/Media/Movies) before, in several-file chunks (5 or so at a time) until one set of movies/chunk refused to transfer because it said there wasn't enough space. So I moved to the user share root (//unraid-ip/Media) and copied my Movies folder itself to the Movies folder on the share.

What is the split level for Media?

I have a user share called Media. Within that I have a personal folder, a work folder and a Movies folder. I had been copying directly within the Movies folder (//unraid-ip/Media/Movies) before, in several-file chunks (5 or so at a time) until one set of movies/chunk refused to transfer because it said there wasn't enough space. So I moved to the user share root (//unraid-ip/Media) and copied my Movies folder itself to the Movies folder on the share.

What is the split level for Media?

 

Shown on the first page -- it's set to automatic, so that shouldn't be an issue.

 

If I transfer my entire Movies directory from my local raid, to the root share where the Movies directory is, the transfer initiates. ~200GB at 30MB/s. Extremely slow but its transferring...

 

30MB/s isn't "extremely slow" when copying to the parity protected array.  With your specific set of disks, that's right about what I'd expect.  If you had higher capacity disks with higher platter densities you'd probably get 40-45MB/s.

 

Do they work okay if you copy one movie at a time (or one folder at a time) ??

 

- First one (3.5 GB) transferred ok, albeit a little slowly (~60MB/s)

- Second one (9GB) started out at ~60MB/s, settled at 40MB/s a few seconds in

- Third one (2.5 GB) started out around 80MB/s, settled at 30-35MB/s. Similar story for the remaining movies. So, seems I can transfer these one by one.

 

Worth noting that before when I was transferring a large number of files at once, I was saturating my network speeds. ~115MB/s read speed from my local raid0 array, ~980Mb/s network speed

 

The first file was largely cached in memory ... so it reported an artificially high copy speed.

The second file was larger, so after the memory cache was full, it settled down to 30MB/s or so ... but the average was around the reported 40.

The third file was probably started before the actual writes for the 2nd had finished, so it didn't get cached -- thus the 30+MB/s range.

 

... and of course the large copy you did that was averaging 30+MB/s didn't benefit from a couple of GB of cached data, since it was such a large copy.

 

So the issue isn't your array's write speeds => it's WHY you're having a problem writing one level deep in the share.

FWIW, the Corsair CX430 is a very low-end power supply that I definitely do NOT recommend.  I don't think that is your issue here; but it's not a bad idea to use a better PSU.

 

I've been looking at the syslog a little more to try to understand what was going on and I think I now understand why disk3 and disk4 seemed to be unmountable at first and then suddenly mounted. I think you started with two data disks and a parity, all of 500 GB capacity. You then added two 2 TB disks knowing that one of them had to be used to replace the parity disk. So you reassigned one of them as parity and the other as disk3, then you reassigned the old parity disk as disk4 and then started the array. The system then started an unprotected expansion.

 

Nov 25 15:11:40 Tower emhttp: Start array...

Nov 25 15:11:40 Tower kernel: mdcmd (38): start UNPROTECTED_EXPANSION

Nov 25 15:11:40 Tower kernel: unraid: allocating 31940K for 1280 stripes (5 disks)

Nov 25 15:11:40 Tower kernel: md1: running, size: 488386552 blocks

Nov 25 15:11:40 Tower kernel: md2: running, size: 488386552 blocks

Nov 25 15:11:40 Tower kernel: md3: running, size: 1953514552 blocks

Nov 25 15:11:40 Tower kernel: md4: running, size: 488386552 blocks

 

This is the point where disk3 and disk4 failed to mount - that is expected because at that point they contained no file systems. You'd then be offered the option of formatting them, which you took and a little later the format finished and they mounted (at around 15:13). Then at 15:15:17 the array was stopped, and started again at 15:15:29 with a parity build starting at 15:15:31 and completing at 20:54:12.

 

Now that I understand what was going on, there doesn't seem to be anything untoward about the syslog, though disk4 still failed SMART self-tests in the past.

 

What I don't understand is why disk3 (one of the new ones) is filling up before disk1 and disk2, given your choice of Allocation Method - unless, of course, you added the files with it set to the default High Water and then changed it to Fill Up afterwards. Can you confirm that that is indeed the case?

 

I have no further suggestions at this point.

 

Ahh ... that makes sense.  I was trying to figure out HOW that could have happened; but didn't think about an incorrect "parity swap" process, which is basically what must have happened.

 

Still doesn't explain why the copies fail when done one level deep, but succeed at the root of the share.  But that may even be related to something that happened in the process of expanding.

 

Method => I'd be inclined to do a "New Config" and be sure you assign the correct disk as parity and the rest as data.

Then let the new parity sync complete (several hours) -- and THEN see if your problem disappears.