readynas rn102 copy internal from c: to d: slow

[Hawk321]

Hello,

Iam copying a big amount of data (6TB) from my c: hdd to the d: hdd. 

First I tried it with Total Commander and mounted therefore the c:/d: als network drivers. I got speeds between 10 mb/s and 15 mb/s.

As this is very slow I tried to use midnight commander using ssh to copy the data internal and not over the network to get faster speeds. Suprisingly this is even slower. I got a speed between 7 mb/s and 10 mb/s.

So is there a way to copy data fast between the two drives?

Thans

[StephenB]

What firmware are you running?

Are you using gigabit ethernet to connect the PC to the NAS?  Or something else (100 mbit ethernet or WiFi?).  Your speeds are about what you'd expect with fast ethernet (assuming you mean megabytes per second and not megabits per second).

Also, is the USB drive USB 3 or USB 2?  What model is it (larger drives are often SMR, which has very slow sustained write times).  How is it formated?

No idea on Midnight Commander, as that's not an application I use.  If the USB drive is connected to the NAS directly, then I'd normally use a backup job in the web ui to copy the data.

[Hawk321]

Hi,

I use 6.10.1 as Firmware and I have Gigabit ethernet.

Iam not using any USB drives, both drives are in the NAS and are the same model. They are white labeld WDD 8 TB drives from WD my books. I try to copy data from hdd C: to Hdd 😧

Midnight commander is a ssh tool like total commander which can be used in the SSH enviroment on the NAS.

https://www.youtube.com/watch?v=uJY6ig9bIg4

Actuel speed:´http://prntscr.com/pdeiki

So I tried now something. I copied a file from a SSD in the network to C: HDD and I got the same speed around 9000 kbytes/s. I copied the same file then to 😧 HDD and got a speed of 30000 kbytes/s.

http://prntscr.com/pdemk3

The only difference between the two HDD`s is that C. is encrypted (ReadyOs) and 😧 isnt. I Think the encryption, I used AES 512, is causing a 66 % slower copy speed comparing to a none encrypted drive. Well that sucks 😞

[StephenB]

---

@Hawk321 wrote:

Hi,

I use 6.10.1 as Firmware and I have Gigabit ethernet.

Iam not using any USB drives, both drives are in the NAS and are the same model. They are white labeld WDD 8 TB drives from WD my books. I try to copy data from hdd C: to Hdd 😧

---

Ok, so you are using WD Reds (re-labeled), configured as JBOD, and with volume names C and D.

---

@Hawk321 wrote:

The only difference between the two HDD`s is that C. is encrypted (ReadyOs) and 😧 isnt. I Think the encryption, I used AES 512, is causing a 66 % slower copy speed comparing to a none encrypted drive. Well that sucks 😞

---

 The RN102 doesn't have hardware acceleration for AES encryption, so it will be slower.  I don't know how much, but 66% is more than I'd expect.  You could also try disabling snapshots on the target system (and perhaps also disable volume quota and btrfs checksums).

Can you try using dd to test the write speed on both volumes?  Here's what I get on my RN102 (using 1 TB Ironwolf drives configured as XRAID)

root@RN102:~# dd if=/dev/zero of=/data/test bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.78328 s, 110 MB/s
root@RN102:~# rm /data/test

[Hawk321]

root@BIGBUBUJR:~# dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=direct
dd: memory exhausted by input buffer of size 1073741824 bytes (1.0 GiB)
root@BIGBUBUJR:~# dd if=/dev/zero of=/root/testfile bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.1802 s, 81.5 MB/s

root@BIGBUBUJR:/# cd /C
root@BIGBUBUJR:/C# dd if=/dev/zero of=/root/testfile bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.1461 s, 81.7 MB/s


root@BIGBUBUJR:/C# cd /D
root@BIGBUBUJR:/D# dd if=/dev/zero of=/root/testfile bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.7516 s, 78.1 MB/s

Iam not sure if this is the right way to test dd on different disks ? Maybe it will always test it on the same disk?

[Hawk321]

root@BIGBUBUJR:/# dd if=/dev/zero of=/root/C/testfile bs=512k count=2048 oflag=direct
dd: failed to open '/root/C/testfile': No such file or directory
root@BIGBUBUJR:/# dd if=/dev/zero of=/C/testfile bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3529.05 s, 304 kB/s

root@BIGBUBUJR:/# dd if=/dev/zero of=/D/testfile bs=512k count=2048 oflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 17.5555 s, 61.2 MB/s

I ran it now on C: and D:. C: is the encrypted HDD and is much slower!

[StephenB]

---

@Hawk321 wrote:
Iam not sure if this is the right way to test dd on different disks ? Maybe it will always test it on the same disk?

---

/root is actually a RAID-1 array of the two disks.  The writes are going to both drives in parallel.

---

@Hawk321 wrote:

C: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3529.05 s, 304 kB/s
D: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 17.5555 s, 61.2 MB/s

I ran it now on C: and D:. C: is the encrypted HDD and is much slower!

---

Yikes.  It will go faster w/o the oflag=direct flag, so maybe retest without that.

But the answer is pretty clear - disk encryption does kill the performance on the RN100

[Hawk321]

root@BIGBUBUJR:/# dd if=/dev/zero of=/C/testfile bs=512k count=2048
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 92.0958 s, 11.7 MB/s

This is without direct flag and simlilar to the speed I get with total comander. So it does kill the speed by 50 MB/s. Damn this is around 80% speed loss.

Will be AES 256 be similar slow as AES 512?

[StephenB]

---

@Hawk321 wrote:
Will be AES 256 be similar slow as AES 512?

---

I'd expect it to be somewhat faster, but I really don't know, since I don't use the encryption feature.

[Hawk321]

From stackexchange:

For practical purposes, 128-bit keys are sufficient to ensure security. The larger key sizes exist mostly to satisfy some US military regulations which call for the existence of several distinct "security levels", regardless of whether breaking the lowest level is already far beyond existing technology.

The larger key sizes imply some CPU overhead (+20% for a 192-bit key, +40% for a 256-bit key: internally, the AES is a sequence of "rounds" and the AES standard says that there shall be 10, 12 or 14 rounds, for a 128-bit, 192-bit or 256-bit key, respectively). So there is some rational reason not to use a larger than necessary key.

A larger key size also resists better to large quantum computer attacks: Using Grover's algorithm, a brute-force attack on any k-bit key block cipher would only take 𝑂(2𝑘/2)
O
(
2
k
/
2
)
steps, so a 256-bit key would still give 128-bit security, while a 128-bit key could be cracked in 2^64 operations, which is doable. But as far as I know, the threat of QC was an ulterior rationalization; also, it does not explain the 192-bit key size. (And quantum computers of this size are not yet in sight for the next some years.)

[Hawk321]

So ReadyNas always decrypts with AES 256 so no chance to use another decryption standard.

I couldnt find the mounted drives with VeraCrypt but I know that people used Veracrypt to decrypt ReadNas Disks.

Any idear how?

[StephenB]

---

@Hawk321 wrote:

I couldnt find the mounted drives with VeraCrypt but I know that people used Veracrypt to decrypt ReadNas Disks.

---

Actually I don't think people did.  Some folks do use VeraCrypt containers on their NAS though.  I believe @Sandshark is one of them - if so, he might recall if there's a post here from someone manually decrypting the disks.

Not sure why you need to do that though. 

[Sandshark]

I use a Veracrypt volume to contain all of my most personal documents (tax returns, list of passwords I rarely use, serial numbers of household items), but it is created on a PC with VeraCrypt and accessed the same way.  The NAS just holds the Veracrypt volume as a file.

I seriously doubt anyone has found a way to use Veracrypt to access an encrypted ReadyNAS volume.  I''ve always assumed the ReadyNAS is using standard BTRFS encryption, and I have seen nothing on the web that indicates Veracrypt can be used to access that.

[StephenB]

---

@Sandshark wrote:

I''ve always assumed the ReadyNAS is using standard BTRFS encryption

The ReadyNAS uses LUKS ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ).  AFAIK, that cannot be decrypted with VeraCrypt - but it's not something I've researched.