2 minutes ago, jonathanm said:

What, exactly, do you mean by that?

on main menu the Parity sync data rebuild is cancelled aka stopped.

7 minutes ago, trurl said:

Is your cache SSD? I was assuming it was but maybe not. As for your screenshot speeds, I think it would be better to do a test without the parity sync going on.

 

I'm not entirely sure what you mean by "disabled sync". Are you saying you stopped the parity sync? I'm not entirely sure what unRAID does with parity until you have completed the parity sync. The screenshot is just indicating parity is invalid. Since I can't see the Array Operations portion of that screen I don't know whether it was actually building parity at that time or not but I assumed it must be since parity isn't valid yet.

 

We really shouldn't even be talking about screenshots anyway when what we really have is a photo. It would be a lot cleaner if in the future you actually gave us a screenshot (screen capture).

 

Study this. It gives a more complete explanation of how realtime parity is maintained and the 2 different methods that can be used, with their tradeoffs.

 

 

 

My Cache is SSD raid 0 that is capable of 500MBps each and I tried copying files from SSD to a remote machine via 10gbe .. I am getting 550MBps + So I am quite positive that the SSD are not the bottle neck here.

 

My problem is when my cache is dumping to the magnetic disks.... it is slow. So slow that even using 1gbps network connection the cache is getting full while transferring files to my hdds. ( so the transfer to disk is much slower than my gigabit transfer speed. )

 

the Parity sync data rebuild is cancelled aka stopped.

 

That is why I was also wondering why my parity disk are being written on..

 

 

 

Edited September 10, 20187 yr by aerosmith9110

Did you take a look at the link I gave? Writing to the parity array is going to be slower than writing to SSD. It is going to be slower than writing to a single HDD.

 

If your intention is to copy a lot of initial data to your server (data load), it probably makes sense to unassign the parity disks, and don't cache any of the data. Then after the initial data load, sync parity and enable caching.

 

If you could tell us how you expect to use your server in day to day operation, such as how much data you expect to transfer in one day after the initial data load is complete, then we could make some suggestions about how to use caching. Writing everything to cache first isn't necessarily the best plan.

10 minutes ago, trurl said:

Did you take a look at the link I gave? Writing to the parity array is going to be slower than writing to SSD. It is going to be slower than writing to a single HDD.

 

If your intention is to copy a lot of initial data to your server (data load), it probably makes sense to unassign the parity disks, and don't cache any of the data. Then after the initial data load, sync parity and enable caching.

 

If you could tell us how you expect to use your server in day to day operation, such as how much data you expect to transfer in one day after the initial data load is complete, then we could make some suggestions about how to use caching. Writing everything to cache first isn't necessarily the best plan.

I am currently in the office and the unraid server is for my home use. I will browse through your link in a bit... ( I wasn't still on the stage on parity thus I didn't set my mind to look into it yet )

 

I am currently transferring files from my qnap to unraid so a lot of info dumping going on.. So, what you are saying reg the parity disk is that when they are assigned even if the Parity sync data rebuild is cancelled aka stopped the parity disk are still working...  ( this I wasn't expecting ) . I thought stopping parity would make the parity really stop that is why i was wonding why there are traffic on the parity disks.

 

I enable cache cause I am trying out features of unraid. I even replaced my motherboard / process / rams, replaced cache, replaced usb just to see how things work.  So if anything unexpected happens I would have some clue...

 

 

 

 

Edited September 10, 20187 yr by aerosmith9110

Parity is realtime. Any time any data disk in the array is written, parity is updated immediately. Reading that link I already gave will clear up a lot I think and might save some more questions.

3 minutes ago, trurl said:

Parity is realtime. Any time any data disk in the array is written, parity is updated immediately. Reading that link I already gave will clear up a lot I think and might save some more questions.

Will do.. the realtime I really didn't know. That sure eliminates majority of the speed hit. I cancelled the sync thinking there will be no more parity running.

 

 

Thanks.

Edited September 10, 20187 yr by aerosmith9110

I removed the parity and getting a bit better around 35 - 45MBps each... So my cache is still getting full w/ only 1gbps lan connection

( even w/ cache and the cache has around 500gb to be transferred.. I have no " prefer " in my shares  only yes and No )

Is this normal even w/o parity? drives are hgst he8

 

Edited September 10, 20187 yr by aerosmith9110

34 minutes ago, aerosmith9110 said:

I have no " prefer " in my shares  only yes and No

Any cache-no share will not have any files moved, even if those files are on cache.

 

Here is a much more detailed explanation of the different "Use cache" settings:

 

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

 

 

38 minutes ago, aerosmith9110 said:

I removed the parity and getting a bit better around 35 - 45MBps each...

Depends on what all is going on. You seem to try to do multiple things at once. Writing without parity should be the speed of the single disk being written. But if other reads or writes are happening at the same time on that same disk then of course it will be slower. For example, is mover also running at the same time?

 

Or possibly you are having hardware issues. A diagnostic that includes the activity might help see if anything like that is going on.

1 hour ago, trurl said:

Any cache-no share will not have any files moved, even if those files are on cache.

 

Here is a much more detailed explanation of the different "Use cache" settings:

 

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

 

 

Depends on what all is going on. You seem to try to do multiple things at once. Writing without parity should be the speed of the single disk being written. But if other reads or writes are happening at the same time on that same disk then of course it will be slower. For example, is mover also running at the same time?

 

Or possibly you are having hardware issues. A diagnostic that includes the activity might help see if anything like that is going on.

Got yah. Will try to observe more.. 

For the cache I only use ' no " and  " yes " .  " prefer " Isn't applicable for me as of the moment... Maybe soon if I start fixing my VMs. 

 

For now I am experimenting on the NAS side of things.

 

Thanks.