gubbgnutten

It wouldn't surprise me if the diagnostics tells us that it is a Marvell chipset problem. But we'll see when they are posted. On a related note - Sorry to hear that you went for a HighPoint card, I hope it works out for you. My Rocket 640L disaster taught me to never ever buy budget controller cards. Much better luck with secondhand quality cards of types commonly used by others in the community.

Buffering in RAM most likely.

Have a look at Services, maybe a troubleshooting session would be appropriate?

Pretty sure all folders have the "problem", just that it is not as visible depending on the file sizes and amount of files. I assume there are 18 files in the 90KB folder?

That diagnostics file seems to be about a week old... Edit: ...and there are a bunch of old incompatible packages loaded. I would guess they are either left over from upgrading the system without removing stuff that should have been removed, or from simply manually installing incompatible plugins. Get rid of them.

That was actually answered in the first reply of this thread, have a closer look at Frank1940's post.

I'm sure there is a perfectly reasonable explanation for the slow release cycles.

Looks like it is generating Video Preview Thumbnails (media index files).

I'd assume your couple of 1TB drives are slowing you down. Monitor the speed during a parity check and you'll find that the parity check speed is low towards the end of the first 1TB of the check and then picks up quite a bit right after the 1TB mark.

Mixed size drives?

Normal and nothing to worry about. Windows is simply misinformed about allocation sizes of the networked drive so the displayed value can be way off.

This is not correct. The LAN might be slowing but most likely the unRAID writes on target side are limiting due to parity calculation. If doing such a massive transfer you should consider switching to "reconstruct write". You can do a full parity build after the transfer is complete. Finally you could do a second rsync run to compare source and destination just to be on the safe side. Well, the example given was an external USB drive connected to the server. Probably USB2 and most likely slower than parity protected writes even without reconstruct write. If we additionally assume that the drive contains tons of files rather than only fewer really large ones, the numbers/slowness make perfect sense. Nasty overhead for smaller files (same goes for regular copying of course)...

Currently? XFS. Unless it is a cache disk that will participate in a cache pool (now or in the future), then BTRFS. Let's face it: you might use unRAID to host virtual machines, but that does not mean everyone else does. My use case is NAS, Plex and mostly sequential access. Not quite sure what you mean by using softraid in this context. I can agree that "it depends" is not very helpful, but "it depends" followed by a question about intended use should not be frowned upon if the answer is different for different cases. Why? You seem to confuse "best choice" with "no choice". Would you be happier if unRAID only provided one sub-par filesystem rather than multiple decent ones? Not sure either why you mentioned OSX, especially considering HPFS was the OS/2 file system. HFS+ is a different beast.

Pretty sure last time this was discussed it was considered "by design" and not a defect, although I must admit that my memory is far from perfect. ^^ If a file on a user share is moved locally it will not be moved to another disk, only moved within the same disk. With operations conducted directly on the server this covers all of /mnt/user, as opposed to over the network where it only applies to moves within the same share. This is why the cache location from one share locally can "leak" to another. Copy and delete the files rather than move them.

Possibly related: You appear to have a bunch of nearly full ReiserFS drives. If for example split levels cause writes to occur on one of those drives, the writes will no doubt be unbearably slow...

Sure, no dockers, but you are running a bunch of plugins... In this case my primary suspect would be cache dirs. Do you still get OOM after a reboot with that one removed?

Have you tried running in safe mode (without plugins)?

It does not matter which filesystem you pick, formatting a drive always results in an empty one. Did you read the link RobJ gave you? Keep that one in mind in the future.

Sounds similar to one of my servers - the first boot is fine but later attempts can't find the boot device. In my case, unplugging and then reconnecting the USB stick always grants me another boot.

From observing the forums I wouldn't agree that there are many users requesting it. And if we only count request accompanied by solid use cases rather than simple "I want it"s, I can almost count them on the fingers of one foot Rather than assuming it is personal, focus on giving some practical use cases. If it is clear what is being asked for and many users want it, I am sure it will be thoroughly considered.

You're not really providing us with anything to work with. Diagnostics would be useful. What's to troubleshoot with the 8GB/s? Too fast? Too slow? You're not accidentally confusing Gb(it)/s for GB(yte)/s?

Your m---a (media) share cache mode is set to "prefer" which means that it moves files from the array to the cache drive if you have one. It is more common to have use cache set to "Yes" for media shares and "Prefer" for appdata shares than the other way around.

By the way, have you had a chance to check out the topic Need help? Read me first! yet? Diagnostics are preferred over syslog snippets.

My diag file is like four posts up and the problem it relates to was solved by another user. So super good contribution here dude. Thanks a lot. Nice attitude, "dude". As you yourself put it - that diagnostics file relates to another problem. Things have changed since then and you have encountered a new problem. That other user you refer to also wrote "Upload a new diagnostics file if you need help", right?

You have a very peculiar definition of "a literal crawl", 30-60MB/s is perfectly reasonable when writing to a non-SSD parity protected array, no matter if it is dual or single parity. Reconstruct write/turbo write might be able to speed things up a bit, don't know if you have explored that. Other than that, given that you refuse cache disks, you could buy more RAM, get faster disks and/or skip parity completely if you want faster writes. As for your slow reads, some of your disks seem to be quite small, which probably means they are quite old. I would not expect miracles reading from those. Not quite sure what does having 8 disks have to do with anything. Sounds like you expect unRAID to do striping. It doesn't. One file is written to/read from one disk, not 1/8 from each disk.