Very slow speeds moving data into new UNRAID

[Econaut]

I just got my first UNRAID server set up and it has about 10TB of space in the array with lots of room to grow. I have a disk that has been storing data temporarily until I can move it into something redundant like this system. The array has a cache ssd set up and I can copy files/folders manually through windows (two samba mounts) and speeds are 40-60MiB/s. Would take a long long time to transfer 5TB or so but can be done in many chunks.

 

Watched numerous spaceinvader one videos and in a few he recommended using Krusader which I set up. Unfortunately I cannot pull the drive and do a direct transfer so it will have to go through the network anyway. I set up a remote NFS share with Unassigned Devices to the storage drive and tried a copy from that NFS share directly to disk 1 on the array (bypassing the cache I believe) and speeds were pretty bad (15MiB/s average). Started off around 40-60 but then tapered down. On another test, transferring to the user share itself (using cache) Krusader sees 60-70MiB/s (still from NFS mounted source). So the source is not limited in this regard but it seems like the target disk is?

 

One of several questions... should I be bypassing the cache drive for importing data? My thoughts were to save it needless cycles as it writes,reads,clears through the several TB's of data.

 

What would be the best speed to expect over a gig Ethernet cable from NFS to UNRAID disk array? Is there a better way to transfer via network?

Edit: tried the same direct to disk1 copy with an SMB share rather than NFS and it is maintaining 40-50MiB/s so that's pretty decent.

Edited September 16, 2021 by Econaut

[Econaut]

Followup question... If there's 4 disks in a share, and most of those disks don't actually show the share folder name yet, is it safe to create/recreate the structure so I can manually copy straight to disk? Or do I need to tell UNRAID to do something so I can direct copy?

[trurl]

Don't cache if you intend to transfer more than cache can hold. Mover is intended for idle time, default schedule is daily in the middle of the night. It is impossible to move from cache to slow array as fast as you can write to cache. If you try to write to cache and run mover at the same time it is only going to add to the load on those same resources.

 

Some people run without parity for the initial load since realtime parity updates slows things down.

 

As for transferring directly to disk instead of user shares, that might (or might not) help some, but is probably not worth the trouble and would make more sense to run without parity instead. As long as you keep the source until you have finished transfer little risk to running without parity.

 

And in any case, you must always have another copy of everything important and irreplaceable. Plenty of ways to lose data that parity won't help with.

[Econaut]

Thanks for the info. Yeah It wouldn't be more than the cache size at once anyway. I am/would be pretty much relying on the parity drive but plan to get a 2nd eventually. Setting up unraid because my aforementioned external has no backup at all lol. Relying on single disk failures and not having them happen in batches is about all I can afford right now.

 

Wondering if since the share is using high water that would explain why I don't see a 'media' folder on any of the other disks & what I can do about that? If I wanted to preload some onto disk2 or 3 for example, those are still completely empty as far as I can see.

[itimpi]

3 minutes ago, Econaut said:

Wondering if since the share is using high water that would explain why I don't see a 'media' folder on any of the other disks & what I can do about that? If I wanted to preload some onto disk2 or 3 for example, those are still completely empty as far as I can see.

UnRaid only creates the folder for a share on a drive when it first writes a file to that drive.

 

there is nothing stopping you manually creating the folder corresponding to the share name on the drive and if you do so UnRaid will automatically consider it as part of the share.

 

[trurl]

1 hour ago, Econaut said:

relying on the parity drive but plan to get a 2nd eventually

What exactly do you mean by "relying"? Parity is not a substitute for backup.

[Econaut]

14 minutes ago, trurl said:

What exactly do you mean by "relying"? Parity is not a substitute for backup.

 

Well allow me to explain and reveal probably how inexperienced I am but here goes... What is a parity drive if not a redundant storage drive (rather, it would let one drive be rebuilt if one drive failed without any data loss) - to me that means, while it's not backed up (same data in 2 systems), it's sort of backed up in the parity data within the same system.

 

Extending that... adding a 2nd parity drive would (as I understand it, but could be wrong) allow for 2 drives to fail in this system and be recoverable with replacement drives and the expectation is that no data would be lost from either of the two failed drives.

 

So in short, I am relying on the parity drive being able to recover one failed drive at a time (and hoping that no more than one drive fail at a time). Of course if two drives fail, I assume I lose everything, maybe - that's where I am at a loss. Or just everything on that one failed drive in any case?

[trurl]

5 minutes ago, Econaut said:

sort of backed up in the parity data

Parity is not a backup in any sense. It obviously doesn't have the capacity to backup any and all data from your array.

 

Parity actually contains none of your data, and parity by itself can recover nothing. Parity is a common concept in computers and communications, and it is basically the same idea wherever it is used. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits.

 

Parity is just an extra disk that allows a missing disk to be calculated from all the other disks.

 

There are many, much more common, ways to lose data besides a failed disk, including user error.

 

13 minutes ago, Econaut said:

if two drives fail, I assume I lose everything, maybe - that's where I am at a loss. Or just everything on that one failed drive in any case?

Each data disk in Unraid is an independent filesystem. Each file exists completely on a single disk. This is basically the way that Unraid differs from traditional RAID.

 

Folders can span disks (user shares).

 

Because each disk is independent, if you lose a disk and can't recover it for some reason, other disks are OK (assuming no problems with them, of course). Note, though, that problems with one disk can mean problems trying to recover another disk, since parity by itself can recover nothing as already mentioned.

 

And, because each disk is independent, you can use different sized disks in the parity array.

 

But, since each file is completely on a single disk (no striping), read speed is at the speed of the single disk containing the file. Write speed is somewhat slower than single disk speed due to realtime parity updates.

 

You can also have multiple pools (usually SSDs) separate from the parity array for faster storage.

 

Note that realtime parity means there is no way parity can help you recover files you accidentally delete, for just one example of common ways to lose data that have nothing to do with disk failure.

 

Sometimes people even make mistakes using Unraid that results in data loss. Be sure to ask if you have any questions before you do anything you don't fully understand.

[trurl]

3 hours ago, trurl said:

And in any case, you must always have another copy of everything important and irreplaceable. Plenty of ways to lose data that parity won't help with.